Both IE 9 & 10 generate a "SCRIPT70: Permission denied" when looping through the parents in the CMS. This happens after data has been edited in a UploadField iframe (eg: submitted Title change), followed by a click on any SiteTree link.
1. Add missing _super calls.
2. Make UI widget destroys more consistent to avoid exceptions.
Selectable would throw an exception in the GridField.js if destroy
called from onunmatch - at that stage jQuery UI would have had called
the destroy already. Add a guard, and change to onremove, which triggers
before the element is removed from DOM.
3. DOM traversal fails after the element is removed from DOM.
Onunmatch triggers after the removal of the element from the DOM, which
makes DOM traversal fail. Use onremove instead, which triggers while the
element is still in DOM.
This is legacy behaviour which does not often reflect the expected behaviour of the current editor. indent and outdent can (in some situations) prefer to use margin instead of padding. sapphiremce_cleanup faultily assumes that such indented text should be block quoted, and replaces this with a block quote element. This is not necessary, since the blockquote element can be placed explicitly by the user when necessary.
To replicate the incorrect indentation behaviour, configure tinymce to use the 'lists' plugin (via admin/_config.php) and attempt to indent some text. Indented text will be unexpectedly replaced with blockquotes.
Also addresses issue #1439.
I don’t like the binding iframe.on('load') events in the onclick handler, but apparently Entwine doesn't support binding on iframes.
AssetAdmin and HtmlEditorField support added
The detection is triggered on first load, and in IE8 the
inserted value doesn't equal the value already in the textarea field.
That's possibly due to whitespace or encoding differences,
but they have the same character length.
Tried fixing this by whitespace removal, didn't work:
if((original || '').replace(/[\s\t\n\r]/g, '') != (value || '').replace(/[\s\t\n\r]/g, '')) {
In the end, we're already detecting changes through a 5s interval
triggering the save() method on the editor if the field is focused.
The impact of this removal is that after inserting an image,
it'll take a few seconds for the change detection to kick in
(and thus highlight the "save" button and ask for confirmation
when navigating away without saving).
See d12ae82f70 for context.
We werent calling tinyMCE.Editor.destroy, which is needed to
clean up event bindings. The advanced theme also wasnt cleaning
up after itself on destroy properly
It doesn't make sense to show it there, since the "delete"
action has no effect, the "edit" button only collapses (useless),
and the thumbnail duplicates.
Wasn't parsing data-editor attrs correctly.
Using proper instances of the underlying editor now,
instead of relying on "active editor" states which get
wonky once they lose focus (e.g. when opening a dialog).
Periodically check for inline changes when focused,
since TinyMCE's onChange only fires on certain actions
like inserting a new paragraph, as opposed to any user input.
This also works around an issue where the "save" button
wouldn't trigger if the click is the cause of a "blur" event
after an (undetected) inline change. This "blur" causes onChange
to trigger, which will change the button markup to show "alternative" styles,
effectively cancelling the original click event.
