Fixed bug #5456: Adjusting Headings style in blank WYSIWYG Content Container disables that container 

When a WYSIWYG element was initially selected, the whole editable element was selected rather than text inside the container. This meant that if a formatting tag (such as a heading) was applied without a further click inside, the editable element would be replaced by the selected format. The symptoms of this were that the "call to action" to enter text would appear formatted with the selected style, and would not appear editable.

Fixed bug #5526: Viper Source View broken in IE9+ 

Due to an issue in the Edit+ build script, the Source View editor in the excluded files from all Internet Explorer browsers which should've been only excluded to IE8 and earlier. This caused the dependent Ace text editor in the Source View plugin to fail to load.

Fixed bug #5548: CTRL+arrow keyboard shortcut disabled after upgrade

The WYSIWYG was disabling access to the Ctrl+arrow keyboard shortcuts on non-Mac systems, which are standard shortcuts for moving cursor by a word. This was done in error: the intent was to block accidental switching of pages within a browser's history (something done with Cmd+arrow on Mac), but the correct shortcut to block this action on non-Mac browsers is Alt+arrow, not Ctrl+arrow.

Fixed bug #5558: Friendly warning information missing when encountering duplicate webpath errors

Due to a misspelled word in the error message sent by the JS API to Edit+ when a file could not be created, the friendly message that was meant to appear on the Creation Wizard results screen instead did not appear. The message was updated in Squiz Matrix 5.0.4.0, however Edit+ 5.0.4 will accept both spellings. (Therefore the minimum requirement does not change from Edit+ 5.0.3, which was Matrix 5.0.3.0.)

Fixed bug #5568: Content is lost after inserting a paragraph break into a line-breaked list of items

A bug was found in the WYSIWYG where, if you created a new paragraph in the middle of a paragraph of lines with hard line breaks (BR tags), and then tried to type, the content after the caret would be lost.

Fixed bug #5575: Users with ability to reject workflow by right of Admin Permission should be able to acquire locks on Workflow Screen

Edit+ never used to acquire locks for users that are located outside of the current workflow step. This is even though users outside the workflow with Admin Permission have the right to either veto the workflow, or approve workflows that are completed but stalled due to originally having incomplete metadata. (It is possible that the original intent was that these users should defer to Admin Mode, but in the context of modern Edit+, this makes little sense.) Now, users in this situation will acquire just a workflow lock on accessing the asset - instead of all locks in a normal editing situation - allowing them to perform their actions on the Workflow screen.