607308 - Document flickers when moving text caret from a table cell to another element if an iframe exists in the document

Status: NEW

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

Description

[Michael Beckius]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)

When moving the text caret from a table cell to any other element inside a contentEditable element, the whole document will flicker/blink IF the document also contains an iframe.

Reproducible: Always

Steps to Reproduce:
1. Create a HTML document with a DIV that is contentEditable.
2. Place a TABLE inside that DIV.
3. Place an IFRAME in the HTML document, before or after the contentEditable DIV (the the value of the iframe's src attribute is not important - about:blank is fine).
4. Load the HTML document in Firefox.
5. Click to place the text caret inside one of the table's cells.
6. Click to move the text caret from the table cell to any other element inside the contentEditable DIV.
Actual Results:  
The whole document flickers/blinks.

Expected Results:  
The document should not flicker/blink.

I have uploaded a simple test case with instructions here: http://www.fanskap.se/firefoxbug/flicker.htm

Simply removing the iframe tag from the document will make the problem go away.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Confirmed with Built from http://hg.mozilla.org/releases/mozilla-1.9.2/rev/8b515f27f430
WFM with Built from http://hg.mozilla.org/mozilla-central/rev/3ddfa411f716
(both on WinXP)

Comment 2

[(no longer active)]

Michael, has this bug affected you in practice?  If yes, may I ask on which website?

Comment 3

[Michael Beckius]

It affects some of our CMS customers of the company where I work. When they edit their pages in the RTE of the CMS, they encounter this bug. They find it annoying and blames our product for it.

Comment 4

[(no longer active)]

roc, do you have any idea what might have fixed it on trunk?  Also, is it the sort of thing we would want to backport to our stable branch?

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Probably some widget removal stuff. I'm not really sure. Someone with a nightly archive could bisect. It's unlikely the fix would be branch material though.

Comment 6

[(mostly gone) XtC4UaLL [:xtc4uall]]

Progression Range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=35059e8e8ce8&tochange=78cf81cafcff

Comment 7

[(no longer active)]

(In reply to comment #6)
> Progression Range:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=35059e8e8ce8&tochange=78cf81cafcff

By regression range, do you mean that the problem happens in 78cf81cafcff and doesn't happen in 35059e8e8ce8, or the other way around?

Comment 8

[(mostly gone) XtC4UaLL [:xtc4uall]]

Errm, i explicitly wrote *Pro*gression, i.e. 35059e8e8ce8 flickers, 78cf81cafcff doesn't ;)

Comment 9

[(no longer active)]

(In reply to comment #8)
> Errm, i explicitly wrote *Pro*gression, i.e. 35059e8e8ce8 flickers,
> 78cf81cafcff doesn't ;)

Heh, I guess my eyes are too used to read "regression"!  ;-)

Could you also have the time to bisect the range so that we can find the exact changeset as well, please?

Comment 10

[(no longer active)]

Although the only thing which looks worth suspecting in that range is <http://hg.mozilla.org/mozilla-central/rev/5b74da35092c> from bug 545593.  CCing Timothy because he wrote that patch.

Comment 11

[Timothy Nikkel (:tnikkel)]

It completely makes sense that bug 545593 would fix this.

Comment 12

[Timothy Nikkel (:tnikkel)]

Looks like we are getting a frame reconstruct for the body, causing us to recreate the iframe, which probably disables refresh and that is when we get the flicker of white. Maybe we can figure something out so that reconstruct isn't needed.

Comment 13

[Timothy Nikkel (:tnikkel)]

The reconstruct is caused by the editor removing the native anonymous content is uses for table editing.

This is fixed for me with the patch in bug 558663, which I think we should take on branches, but it caused some regressions on trunk that need to be worked out first. It exposes bug 572938 as well, which has a patch now. I've honestly forgotten exactly what we need exactly to take that bug on branches.

Comment 14

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.