Open Bug 207842 Opened 17 years ago Updated 12 years ago

Midas: Setting designMode on for the first iframe doesn't work

Categories

(Core :: DOM: Editor, defect, major)

x86
Windows XP
defect
Not set
major

Tracking

()

People

(Reporter: emaijala+moz, Assigned: Brade)

References

Details

(Keywords: testcase, Whiteboard: midas)

Attachments

(5 files)

I have a page that creates an iframe using document.writeln() and then sets the
designMode on for the iframe. On a newly created browser window this seems to be
successful (no errors in js console), but the content cannot be edited. If I
reload the page, it will work correctly. 

If there are two iframes on a page (created in the same way) and designMode is
set on for both of them, only the second one will ever work. I'll attach a
simple test case.
Looks like execCommand() doesn't work at all even if the iframe content can be
edited. This can be worked around by setting the designMode via setTimeout() but
that's a hack.
Ere--when you see failures, are you seeing designMode="on" succeeding?
Whiteboard: midas
Something has regressed since the trunk build of 2003060208. Now all test cases
are completely broken. Setting regression keyword as things are even worse than
before.
Keywords: regression
Oops, no regression here, just some bad code in test.
Keywords: regression
Firstly I can say that I have the same symptoms in a XUL context where I insert
<editor> tags through a button (click on the button performs
document.createElementNS etc. then insert the element, then set the element's
contentDocument.designMode to 'on').

The second editor get editable, but execCommand silently fails, the first editor
refuses text input.

Besides, the DOM Inspector shows that designMode="off" for both editors.

In a second step, I performed further tests, trying to put the "designMode='on'"
somewhere else than just after the insertion of editor element in the DOM.

I got a new kind of error in some cases : the window seems to enter in a loop
and the mouse cursor aspect alternates from a normal aspect to a wait cursor
aspect (arrow + hourglass).

E.g. this happens when putting designMode='on' in a onfocus handler of the
editor element, and calling it's focus() method after the element insertion in
the DOM. The first insertion is ok, first editor works fine (even execCommand),
but when inserting the second one, the loop starts.

After different tries my feeling is that designMode should not be set to 'on' in
the event propagation cycle (I don't know how to name this I am not familiar
with the event model) where the editor has been inserted.


I can be more precise and provide test cases but I am not sure it's the same bug
than the original one.

Opinions ?
instructions to run the tests are in the archive.

you should execute the test from your chrome directory :
. copy files into one of your existing chrome content dir e.g. 
  chrome://test/content/
. execute mozilla --chrome chrome://test/content/test.xul
Attached file Minimized testcase
This minimized testcase shows that mozilla fails to focus the dynamically
created iframe. Reloading the page makes it works as expected. If testcase
works, then shut down Mozilla and try again.
Keywords: testcase
Severity: normal → major
I've found a similar problem that may or may not be related.
On this page
http://derekdev.com/mozilla/iframenoworky.html
An iframe is created and added to the document and then has its designMode
turned on. The designMode stays on until the script stops executing, then it
turns off. Click the button to see that it is indeed off.

My workaround was this
http://derekdev.com/mozilla/iframeworky.html
The iframe turns itself on after it's loaded.
*** Bug 186057 has been marked as a duplicate of this bug. ***
QA Contact: bugzilla → editor
Blocks: 424615
You need to log in before you can comment on or make changes to this bug.