Opened 8 years ago
Closed 8 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)
Change History (11)
Changed 8 years ago by
Attachment: | test_1_8_3.html added |
---|
comment:1 Changed 8 years ago by
Owner: | changed from bill to Michael Weimann |
---|---|
Status: | new → pending |
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 8 years ago by
Component: | Dijit → Editor |
---|
comment:3 Changed 8 years ago by
Status: | pending → new |
---|
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 8 years ago by
Milestone: | tbd → 1.9 |
---|---|
Owner: | changed from Michael Weimann to bill |
Status: | new → assigned |
Summary: | html editor with FontChoice and multiple editors crashes IE7 and IE9 → html editor with FontChoice and multiple editors hangs on IE7 and IE9 |
Ah I see, OK I reproduced it.
comment:5 Changed 8 years ago by
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(); };
comment:7 Changed 8 years ago by
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.
comment:8 Changed 8 years ago by
Milestone: | 1.9 → 1.7.5 |
---|
HTML file to reproduce the defect