616394 - Firefox 4 doesn't re-size multiple TinyMCE instances correctly

Status: RESOLVED FIXED

(Core :: Layout, defect, P1)

Description

[Mike]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b8pre) Gecko/20101202 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b8pre) Gecko/20101202 Firefox/4.0b8pre

When dragging the bottom right corner to adjust the size of the
editor, the content contained (or added) in the editor does not adjust to fit
the newly "saved" dimensions of the editor UI. 

When increasing the size of the editor, the content does not re-flow to fill
the UI, but remains constrained to the previous UI dimensions.

When decreasing the size of the editor, the content flows outside the UI's new
dimensions, overlapping other content on the page including other instances of
the editor. You can see this on the test case by simply decreasing the size of
the second editor.

After refreshing (ctrl+r or F5) the page, the content will re-flow to properly
fill the newly "saved" UI dimensions.

As best I can tell this only triggers when there are multiple instances of the
editor on the same page. It also seems there is usually one instance of the
editor that is NOT affected. In the test case here, it's the first instance; on
my WordPress installation (that also has 3 instances in place), the third
instance functions properly.

Reproducible: Always

Steps to Reproduce:
1. Open the attached URL.

2. Attempt to adjust the size of the editor by dragging the bottom right corner. The issue is most easily reproduced by reducing the size of the second instance of the editor.

3. Observe that only one of the editor instances properly re-sizes, in this case the first instance.
Actual Results:  
When decreasing the size of the editor, the content flows outside the UI's new
dimensions, overlapping other content on the page including other instances of
the editor.

Expected Results:  
The content within the editor should re-flow to fill the new dimensions. 

This could possibly be related to Bug 605481: https://bugzilla.mozilla.org/show_bug.cgi?id=605481

Comment 1

[(no longer active)]

This happens on the 2nd and 3rd editor on the test page.

Comment 2

[(no longer active)]

Olli, could this also be a fallout from bug 557398?

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK, so the nsSubDocumentFrame itself is resizing.  However the content inside it is not.

Comment 4

[(no longer active)]

(In reply to comment #3)
> OK, so the nsSubDocumentFrame itself is resizing.  However the content inside
> it is not.

Shouldn't we be reflowing the stuff below it?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yeah, this is also fallout from bug 557398; I missed this issue while patching bug 605481.  In particular, say we end up in the situation of bug 605481, so that nsSubDocumentFrame::ReflowFinished ends up called when mFrameLoader is null.  The patch for that bug makes sure we set the correct size on the frameloader when we do finally create it.  But if we ended up in that case, then mPostedReflowCallback remains set to true, so a later reflow won't post a reflow callback, there won't be any more ReflowFinished calls, and we'll never update the frameloader size and hence the size of the document it contains.

Simple fix coming up.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Make sure to set mPostedReflowCallback to false even if we have no frameloader when the callback happens.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I still have no idea how to write a test for this.  :(

Comment 8

[(no longer active)]

Right, sorry.  I'd put [needs to block] in the sw field, but I guess I'll just stop and cool down.  :-)

Comment 9

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/mozilla-central/rev/e6267230056e