Opened 12 years ago
Closed 12 years ago
#9949 closed defect (fixed)
dijit.Editor throws errors on FF3 if Editor is hidden in accordian pane on startup
Reported by: | Jared Jurkiewicz | Owned by: | Jared Jurkiewicz |
---|---|---|---|
Priority: | high | Milestone: | 1.4 |
Component: | Editor | Version: | 1.3.2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
dijit.Editor throws errors on FF3 if Editor is hidden in accordian pane on startup
This can easily be seen with:
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/editor/tests/editorPrettyPrint.html
When it loads.
This is because since the doc is hidden, the queryCommand* functions all fail (throw exception).
Easy fix for this is to squetch the errors, as the queryCommands all rerun when it's brought into view, clicked on, etc, anyway.
Patch forthhcoming.
Bill, You okay with this?
Attachments (1)
Change History (5)
Changed 12 years ago by
Attachment: | squelchError.patch added |
---|
comment:1 Changed 12 years ago by
Owner: | changed from bill to Jared Jurkiewicz |
---|
I'm OK with it although the alternative is that when the Editor is the child of a layout container, to defer running that initialization code until the editor is shown (at which point Editor.resize() gets called).
var parent = dijit._Contained.prototype.getParent.call(this); if(parent && parent.isLayoutContainer){ // i'm the child of a layout widget.... // defer initialization until resize() is called ... }
You said those methods are all rerun when the editor is brought into view? How does the editor detect being brought into view?
comment:2 Changed 12 years ago by
Milestone: | tbd → 1.4 |
---|
comment:3 Changed 12 years ago by
Any clicks on editor generate a onNormalizedDisplayChange event, and that drives a state checking of all the icons. so any interactions with the editor drive it rechecking what should (or shouldn't) be enabled.
comment:4 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Simple patch.