Closed Bug 616394 Opened 9 years ago Closed 9 years ago
Firefox 4 doesn't re-size multiple Tiny
MCE instances correctly
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
Component: General → Editor
Product: Firefox → Core
QA Contact: general → editor
This happens on the 2nd and 3rd editor on the test page.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Olli, could this also be a fallout from bug 557398?
OK, so the nsSubDocumentFrame itself is resizing. However the content inside it is not.
(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?
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.
I still have no idea how to write a test for this. :(
Assignee: nobody → bzbarsky
Component: Editor → Layout
Priority: -- → P1
QA Contact: editor → layout
Whiteboard: [need review]
Attachment #495077 - Flags: review?(roc) → review+
Whiteboard: [needs landing] → [needs approval]
Whiteboard: [needs approval] → [need approval]
Right, sorry. I'd put [needs to block] in the sw field, but I guess I'll just stop and cool down. :-)
blocking2.0: ? → final+
Whiteboard: [need approval] → [need landing]
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [need landing]
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.