Firefox 4 doesn't render multiple TinyMCE instances correctly

RESOLVED FIXED in mozilla2.0b8

Status

()

Core
DOM: Core & HTML
P1
normal
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Spocke, Assigned: bz)

Tracking

({regression})

Trunk
mozilla2.0b8
x86
All
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?
in-litmus ?

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 ( .NET CLR 3.5.30729; .NET4.0E)
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b8pre) Gecko/20101019 Firefox/4.0b8pre

Firefox 4 doesn't render multiple editable iframes correctly in TinyMCE. The body becomes 10x10 pixels in size should be the width/height of a normal document body inside an iframe. This is a regression in behavior from Firefox 3 and it works correctly on all other browsers as well.

Reproducible: Always

Steps to Reproduce:
1. Open the attached URL.
2. Observe that only one of the editor instances gets contents rendered.
3. Try editing the ones that doesn't get contents. Notice that the body is 10x10 in size.
Actual Results:  
Body element gets rendered to small 10x10 pixels.

Expected Results:  
Should be auto in other words the width/height should be the size of the contents not a fixed value.
(Reporter)

Updated

7 years ago
blocking2.0: --- → ?
Version: unspecified → Trunk
Confirmed on XP with a Build built from http://hg.mozilla.org/mozilla-central/rev/cfd18201f49b.
Shouldn't this be in Editor?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
I think this might be an editor bug too.
Ehsan, could you have a look?

Spocke, do you think you can found since when this is broken?
Severity: major → normal
(Reporter)

Comment 3

7 years ago
I managed to pinpoint it to the nightly build of 2010-04-14 tested the Mac version, this is the first nightly that introduced the bug.

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/04/2010-04-14-03-mozilla-central/

Comment 6

7 years ago
OK, I bisected this:

changeset:   40755:ac0109fc6043
user:        Olli Pettay <Olli.Pettay@hilsinki.fi>
date:        Wed Apr 14 11:33:47 2010 +0300
summary:     Bug 557398, Show (i)frames asynchronously, r=jst sr=roc

Olli, can you take a look, please?
Assignee: nobody → Olli.Pettay
Blocks: 557398
Keywords: regressionwindow-wanted

Updated

7 years ago
Status: NEW → ASSIGNED
Blocking.
blocking2.0: ? → betaN+
Olli, mind if I just steal this?  I agree that this looks like the same issue as bug 595752, and I think I have a decent handle on what's needed to fix this.

Comment 9

7 years ago
Feel free to take this. You know layout code a lot better than I do.

Updated

7 years ago
Assignee: Olli.Pettay → bzbarsky
Created attachment 487233 [details] [diff] [review]
and bug 595752.  When showing a frameloader, give it the correct size up front, so we don't depend on the ordering of Show() and reflow of the subdocument frame.
Attachment #487233 - Flags: review?(Olli.Pettay)
I wish I knew how to write a sane test for this... would need something that triggers a layout flush before the scriptrunner calling Show() fires; presumably this would need to be another scriptrunner that gets added during the same update batch.  So any test I write would be pretty fragile.  :(
Priority: -- → P1
Whiteboard: [need review]

Updated

7 years ago
Attachment #487233 - Flags: review?(Olli.Pettay) → review+

Comment 12

7 years ago
(In reply to comment #11)
> I wish I knew how to write a sane test for this... would need something that
> triggers a layout flush before the scriptrunner calling Show() fires;
> presumably this would need to be another scriptrunner that gets added during
> the same update batch.  So any test I write would be pretty fragile.  :(

Can't we have a reftest, with 605481-1.html containing two or three editable iframes, and 605481-1-ref.html containing the exact same iframes, only not editable?
I have yet to figure out a testcase that reproduces the bug, period (other than the huge page in this bug and the throttled situation in bug 595752).  If you have a reasonably small one that shows the problem, I'd love to know!
Whiteboard: [need review] → [need landing]

Comment 14

7 years ago
Hmm, I can't seem to reproduce it with normal designMode iframes...
Right; that was my issue.

If someone can figure out what TinyMCE is doing to even put content in the iframes, that would be good...
(Reporter)

Comment 16

7 years ago
We basically generate a dynamic iframe and use document.open/write/close to insert a body structure, then load some CSS files and finally we set the contents of the body. It looks like some timing issue since when I tested on various builds to pinpoint the exact one that caused the problem different editors got rendered correctly. So making a simple test might be to fast?
Spocke, this is most definitely a timing issue; see comment 11.

A far as comment 16 goes, what's the exact order?  createElement the iframe, appendChild the iframe, open/write/close?  Then change some styles on the iframe?  Then "set the contents of the body" whatever that means in this case?  Where in this sequence are things made editable and how?  I'd really like to make sure we don't break this again and all.  ;)

Comment 18

7 years ago
There's also another option for testing this: shipping the TinyMCE version which reproduces the problem, but I'm not sure if that's the best approach.
That might not be a bad idea, per se, if we also know what calls we need to make to trigger the problem...

Comment 20

7 years ago
(In reply to comment #19)
> That might not be a bad idea, per se, if we also know what calls we need to
> make to trigger the problem...

Well, we could just copy the test case web page, couldn't we?
Maybe.  With all its files (several JS and CSS files involved).  And we'd need to make sure to run it from http, etc....  Doable, but painful.  ;)

Comment 22

7 years ago
(In reply to comment #21)
> Maybe.  With all its files (several JS and CSS files involved).  And we'd need
> to make sure to run it from http, etc....  Doable, but painful.  ;)

I think we can in-litmus? this for now if you agree.  I'm going to integrate a bunch of editing widgets into our test suite after 2.0, and TinyMCE could be one of them...
Works for me!
Flags: in-testsuite?
Flags: in-litmus?
Pushed http://hg.mozilla.org/mozilla-central/rev/4467f70ed6df
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Whiteboard: [need landing]
Target Milestone: --- → mozilla2.0b8

Comment 25

7 years ago
(In reply to comment #24)
> Pushed http://hg.mozilla.org/mozilla-central/rev/4467f70ed6df

Whoohoo, thanks a lot! This commit seems to fix the (rather annoying) problem. :)

Running an up-to-date Minefield here using the latest TinyMCE (3.3.9.2). And I'm pretty confident it will work with older versions of TinyMCE too. :)

Comment 26

7 years ago
Hi - total Bugzilla noob, long time Firefox user here,

I'm using firefox-4.0b8pre.en-US.win64-x86_64 on Win 7 (updated this morning).

I'm still seeing a related issue when resizing the editor interface (height and/or width). 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.

This can be reproduced on http://tinymce.moxiecode.com/examples/skins.php

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.

I don't know if this is the same issue that was thought to be resolved or if a new bug should be started...
New bug, please!
You need to log in before you can comment on or make changes to this bug.