737784 - WYSIWYG editor in Mambo ceases to visualise following update to Firefox 11 (TinyMCE)

Status: RESOLVED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Chris Wood]

User Agent: Mozilla/5.0 (Windows NT 5.2; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120312181643

Steps to reproduce:

Allowed Firefox to autoupdate


Actual results:

The Primary WYSIWYG editor window in MAMBO 4.6.5 no long shows any content. The only way to edit/add is to go into raw HTML and hand edit.

The secondary WYSYWYG editor window however visualises perfectly.

This occurs on Win2003Server and Windows7. I've cross checked in Explorer and Safari - all works fine there.

I'm going to attemt to rollback . shame there is no rollback fuction in Firefox update!.

Comment 1

[Chris Wood]

Just rolled back to Firefox 10.0.2 - problem gone. mambo WYSYWIG editor now funcions correctly.

Comment 2

[Alice0775 White]

I can confirm on Mambo demo page.
The editor does not work in Firefox 11 and later.

Step To Reproduce:
1. Start Firefox with clen profile
2. Open http://www.opensourcecms.com/scripts/details.php?scriptid=44
3. Click "Demo Main Page" button (before click, you memorize username and password listed below the button)
4. Enter username & password and Click LOGIN button
5. Edit icon in "Welcome to Mambo!  ( Public )"
6. Click first editor body

Actual Results:
  Cannot focus. Cannot position caret.
  Cannot type any text
  Editer does not work

Expected Results:
  Editer should work properly


Regression window(cached m-c)
Works:
http://hg.mozilla.org/mozilla-central/rev/cb70391c86d9
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111205 Firefox/11.0a1 ID:20111205043819
Fails:
http://hg.mozilla.org/mozilla-central/rev/fafaf614791f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111206 Firefox/11.0a1 ID:20111206031117
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb70391c86d9&tochange=fafaf614791f


Regression window(cached m-i)
Works:
http://hg.mozilla.org/integration/mozilla-inbound/rev/03420089b4af
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111205 Firefox/11.0a1 ID:20111205030218
Fails:
http://hg.mozilla.org/integration/mozilla-inbound/rev/d991d9770292
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111205 Firefox/11.0a1 ID:20111205045018
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=03420089b4af&tochange=d991d9770292

Suspected: Bug 699351

Comment 3

[Alice0775 White]

In local build
Last good:78d0b89c9800(incl.d991d9770292)
First bad: f08d9c2c8fef(incl.d991d9770292)

Triggered by:
f08d9c2c8fef	Robert O'Callahan — Bug 699351. Part 3: Fix clipping to subdocument to not use subdocument root view bounds. r=tnikkel

Comment 4

[Martijn Wargers (dead)]

Attachment: script that sets designmode

I tried to get a minimized testcase, but I failed. This is at least the script that sets designMode to the iframes (this js file is inserted from tiny_mce_gzip.js ).

Not sure why this triggers the content of the first iframe to be blank.
I noticed that resizing the designMode iframe or setting it to display: inline makes the content appear and editable.

Comment 5

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

The new code depends on mInnerView's bounds being set correctly. Unfortunately, the width and height are 0,0 in this case.

Comment 6

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

Attachment: fix

This fixes it.

I'm not sure what actually triggers this bug, so I don't have a test. Presumably we somehow reflow the nsSubdocumentFrame before EnsureInnerView is ever called.

Comment 7

[Timothy Nikkel (:tnikkel)]

Comment on attachment 608199 [details] [diff] [review]
fix

Wonder why we didn't do it this way before.

Comment 8

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/4790b56fe677

Comment 9

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/4790b56fe677

Comment 10

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

Comment on attachment 608199 [details] [diff] [review]
fix

Review of attachment 608199 [details] [diff] [review]:
-----------------------------------------------------------------

Risk analysis: relatively low risk. Eagerly does something that we used to do lazily (but would almost always do almost immediately anyway). This is quite a severe regression, breaking core Mambo functionality.

Comment 12

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

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #10)
> Risk analysis: relatively low risk. Eagerly does something that we used to
> do lazily (but would almost always do almost immediately anyway). This is
> quite a severe regression, breaking core Mambo functionality.

... And TinyMCE.

Comment 13

[Alex Keybl [:akeybl]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #12)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #10)
> > Risk analysis: relatively low risk. Eagerly does something that we used to
> > do lazily (but would almost always do almost immediately anyway). This is
> > quite a severe regression, breaking core Mambo functionality.
> 
> ... And TinyMCE.

Is there something in particular we can grep for on the web to see the full impact of this regression?

Comment 14

[Alex Keybl [:akeybl]]

Comment on attachment 608199 [details] [diff] [review]
fix

[Triage Comment]
Approved for Aurora 13 and Beta 12. This shouldn't affect the ESR10 though.

Comment 15

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

https://hg.mozilla.org/releases/mozilla-beta/rev/7f0430a6cad1
https://hg.mozilla.org/releases/mozilla-aurora/rev/e64001c17c65

Comment 16

[juan becerra [:juanb]]

A Google search finds Mambo or TinyMCE and Firefox 11 as some of the top results, pointing to forum entries where people report the problem. They also report updating their TinyMCE installations which fixes the problem, but for some people updating TinyMCE is a bit involved so they are waiting for a fix or other suggestions.

Comment 17

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

(In reply to Alex Keybl [:akeybl] from comment #13)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #12)
> > (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #10)
> > > Risk analysis: relatively low risk. Eagerly does something that we used to
> > > do lazily (but would almost always do almost immediately anyway). This is
> > > quite a severe regression, breaking core Mambo functionality.
> > 
> > ... And TinyMCE.
> 
> Is there something in particular we can grep for on the web to see the full
> impact of this regression?

I can't think of anything.

Comment 18

[Mark Pearson]

A google search of 'Tinymce firefox 11' will reveal that it affects at least the following:
Drupal 6 (and possibly 7), Moodle 2.1, concrete5, plone, modx.
This bug has proven a major major hassle to moodle admins like myself.

Comment 21

[Martijn Wargers (dead)]

I have an unminimized testcase here that shows the issue:
http://people.mozilla.org/~mwargers/tests/unminimized/mambo/index.php.htm
If wanted I could get reduced testcase.

Comment 25

[K Chayka]

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #21)
> I have an unminimized testcase here that shows the issue:
> http://people.mozilla.org/~mwargers/tests/unminimized/mambo/index.php.htm

I don't know if this will help at all, but I had a similar problem with a Seamonkey nightly build upgrade and a CMS with multiple editor controls. It turned out to be a caching issue with the tinymce gzip compressor, which is also being used in your testcase. After I removed the files created by tiny_mce_gzip.js it cleared right up.

Comment 26

[Marek Stępień [:marcoos, inactive]]

Maybe this should be added to "known issues" in Firefox 11 relnotes?

Comment 27

[Martijn Wargers (dead)]

Attachment: testcase

Comment 29

[Vlad [QA]]

Verified on:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0 beta 5
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0 beta 5
Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0 beta 5

I have used the steps from comment2 and also the test case from comment27 and the the Mambo editor is working as expected and also the text is visible in the test case.

Marking this as verified on Firefox 12 Beta.

Comment 30

[rlintern]

FYI. Also a problem with Dojo's dijit rich text Editor. See my comments in likely duplicate https://bugzilla.mozilla.org/show_bug.cgi?id=736518

Comment 32

[Vlad [QA]]

Verified on:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0 beta 3
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0 beta 3
Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0 beta 3

I have used the steps from comment2 and the the Mambo editor is working as expected.

Marking this as Verified Fixed on Firefox 13 beta