html editor with FontChoice and multiple editors hangs on IE7 and IE9

[Michael Weimann]

The error can be reproduced with the attachment "test_1_8_3.html".

• Open the file "test_1_8_3.html" inside IE9 (or IE7)
• Click into the textarea of the first editor field
• Click into the font select of the first editor field
• Click into the textarea of the second editor field

The result is, that the browser doesn't respond any more.

The JavaScript? profiler data is also available as and attachment of this ticket.

[Michael Weimann]

HTML file to reproduce the defect

[Michael Weimann]

JS profiler data

[bill]

I tried this in IE9 and IE7 and it worked for me, except for a glitch that clicking the textarea of the second editor actually causes focus to return to the textarea of the first editor. What did you mean by "crash"?

Also, when you said "click into the font select", you meant clicking so that the caret is right after the word "serif"?

[Michael Weimann]

Crashes means that the browser doesn't respond any more and causes a high CPU usage. The JavaScript? seems to run in an infinit loop (see profiler data). I'm able to reproduce it doing the following things using an Internet Explorer 7/9:

• open the test page
• click inside the lower right of the text field of the first editor (so that there is the "normal" mouse pointer and not the text mouse pointer)
• click behind the font select text "Serif" of the first editor
• click inside the lower right of the text field of the second editor (so that there is the "normal" mouse pointer and not the text mouse pointer)

After that the browser doesn't respond any more and causes high CPU usage.

[bill]

Ah I see, OK I reproduced it.

[bill]

Doug can you take a look at this? I think the root issue is with FilteringSelect's onChange notification.

The hang happens because focus keeps shifting between the editors forever. The problem starts when you blur the first editor's font choice FilteringSelect by clicking the second editor. Even though the user hasn't changed the FilteringSelect's value, the FilteringSelect for some reason fires an onChange event. Due to the delay in onChange notifications, it's not until after the second editor gets focus that the callback code below in FontChoice.js runs:

this.own(this.button.select.on("change", lang.hitch(this, function(choice){
        // User invoked change, since all internal updates set priorityChange to false and will
        // not trigger an onChange event.
        this.editor.focus();
        ...

The intention of the this.editor.focus() call is that after the user selects a font, focus is moved from the FilteringSelect back to the editor content. However, since focus has already shifted to the second editor, this focus() call is bad.

I could workaround the problem by putting a if(this.editor._focused){ ... } around the this.editor.focus() call, but it seems like the root issue (greatly exacerbated by the setTimeout delay in onChange notifications) is that the FilteringSelect is firing an unwanted onChange notification.

FYI, this code in RichText.js seems related to the hang, probably because the iframe onfocus event also occurs on a delay:

this.iframe.onfocus = function(){
	_this.editNode.setActive();
};

[bill]

In [30844]:

guard code to not try to move focus from toolbar to textarea when focus has been removed from the editor completely, refs #16680 !strict

[Douglas Hays]

I think bill's guard code is the correct fix. This hangs IE even when the font actually changes. If you select the font-choice and arrow down several times, the font choice input box changes value (but no onChange fires since you haven't selected a choice or blurred out which effectively does a select). So as soon as you click another editor, the blur event fires onChange, which Editor then incorrectly tries to re-estabish focus. In the original scenario, the font choice didn't appear to change, but it did when the textarea was focused, and Editor set the font choice with priorityChange=false (fire onChange later). I think this should have been priorityChange=true and then the original problem is fixed, but the guard code is still needed for the down arrow scenario described here, so it might as well be in place to solve both scenarios.

[Douglas Hays]

In [30984]:

Fixes #16680. Don't allow Editor to move the focus from the toolbar to the textarea if the widget has lost focus. !strict