Opened 7 years ago

Closed 6 years ago

#16680 closed defect (fixed)

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

Reported by: Michael Weimann Owned by: Douglas Hays
Priority: undecided Milestone: 1.7.5
Component: Editor Version: 1.8.3
Keywords: Cc:
Blocked By: Blocking:

Description

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.

Attachments (2)

test_1_8_3.html (1.6 KB) - added by Michael Weimann 7 years ago.
HTML file to reproduce the defect
dojo_1_8_3_profiler.csv (47.6 KB) - added by Michael Weimann 7 years ago.
JS profiler data

Download all attachments as: .zip

Change History (11)

Changed 7 years ago by Michael Weimann

Attachment: test_1_8_3.html added

HTML file to reproduce the defect

Changed 7 years ago by Michael Weimann

Attachment: dojo_1_8_3_profiler.csv added

JS profiler data

comment:1 Changed 7 years ago by bill

Owner: changed from bill to Michael Weimann
Status: newpending

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"?

comment:2 Changed 7 years ago by bill

Component: DijitEditor

comment:3 Changed 7 years ago by Michael Weimann

Status: pendingnew

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.

comment:4 Changed 7 years ago by bill

Milestone: tbd1.9
Owner: changed from Michael Weimann to bill
Status: newassigned
Summary: html editor with FontChoice and multiple editors crashes IE7 and IE9html editor with FontChoice and multiple editors hangs on IE7 and IE9

Ah I see, OK I reproduced it.

comment:5 Changed 7 years ago by bill

Owner: changed from bill to Douglas Hays

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();
};
Last edited 7 years ago by bill (previous) (diff)

comment:6 Changed 7 years ago by 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

comment:7 Changed 6 years ago by 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.

Last edited 6 years ago by Douglas Hays (previous) (diff)

comment:8 Changed 6 years ago by Douglas Hays

Milestone: 1.91.7.5

comment:9 Changed 6 years ago by Douglas Hays

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.