If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

NEW
Assigned to

Status

()

Core
Editor
--
major
15 years ago
10 years ago

People

(Reporter: Ere Maijala (slow), Assigned: Kathleen Brade)

Tracking

({testcase})

Trunk
x86
Windows XP
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: midas)

Attachments

(5 attachments)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
Created attachment 124667 [details]
A simple testcase with two iframes
(Reporter)

Comment 2

15 years ago
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.
(Assignee)

Comment 3

15 years ago
Ere--when you see failures, are you seeing designMode="on" succeeding?
Whiteboard: midas
(Reporter)

Comment 4

15 years ago
Created attachment 124842 [details]
Testcase where execCommand fails for a newly created iframe
(Reporter)

Comment 5

15 years ago
Created attachment 124848 [details]
Testcase where execCommand for bold seems to work but does not have any effect
(Reporter)

Comment 6

15 years ago
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
(Reporter)

Comment 7

15 years ago
Oops, no regression here, just some bad code in test.
Keywords: regression

Comment 8

14 years ago
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

14 years ago
Created attachment 131224 [details]
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

14 years ago
Created attachment 146979 [details]
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.

Updated

14 years ago
Keywords: testcase

Updated

14 years ago
Severity: normal → major

Comment 11

13 years ago
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

12 years ago
*** Bug 186057 has been marked as a duplicate of this bug. ***
Blocks: 307458
QA Contact: bugzilla → editor

Updated

10 years ago
Blocks: 424615
You need to log in before you can comment on or make changes to this bug.