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

Status: NEW

(Core :: DOM: Editor, defect)

Description

[Ere Maijala (slow)]

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.

Comment 1

[Ere Maijala (slow)]

Attachment: A simple testcase with two iframes

Comment 2

[Ere Maijala (slow)]

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.

Comment 3

[Kathleen :Brade]

Ere--when you see failures, are you seeing designMode="on" succeeding?

Comment 4

[Ere Maijala (slow)]

Attachment: Testcase where execCommand fails for a newly created iframe

Comment 5

[Ere Maijala (slow)]

Attachment: Testcase where execCommand for bold seems to work but does not have any effect

Comment 6

[Ere Maijala (slow)]

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.

Comment 7

[Ere Maijala (slow)]

Oops, no regression here, just some bad code in test.

Comment 8

[Cedric. S.]

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 ?

Comment 9

[Cedric. S.]

Attachment: 5 tests to reproduce the cursor loop bug & the first insertion bug, and the workaround

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

Comment 10

[José Jeria]

Attachment: 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.

Comment 11

[Derek Davenport]

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.

Comment 12

[Andrew Schultz]

*** Bug 186057 has been marked as a duplicate of this bug. ***

Comment 13

[Virginia (please send need info request to Brindusa Tot)]

Hi,

I opened the test pages provided on the previous comments but I couldn't understand what the issue is. I also tried opening the page with a workaround as per comment #c11 but page seems to be down.

Could you please check if this is still an ongoing issue and if so, how can I reproduce it?

Thanks,
Virginia

Comment 14

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Virginia Balducci from comment #13)

Hi,

I opened the test pages provided on the previous comments but I couldn't understand what the issue is. I also tried opening the page with a workaround as per comment #c11 but page seems to be down.

Could you please check if this is still an ongoing issue and if so, how can I reproduce it?

Thanks,
Virginia

This is still an issue. designMode was set to "on" in window.onload() but it didn't work as expected, so users cannot type into the element.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last months and this bug has severity 'major'.
:hsinyi, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 17

[Henri Sivonen (:hsivonen)]

Yet another manifestation of bug 543435.