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

RESOLVED FIXED in Firefox 12

Status

()

Core
Layout: HTML Frames
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: Chris Wood, Assigned: roc)

Tracking

({regression, testcase})

11 Branch
mozilla14
x86
All
regression, testcase
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox11+ affected, firefox12+ verified, firefox13+ verified, firefox-esr10 unaffected)

Details

(Whiteboard: [qa+])

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
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!.
(Reporter)

Comment 1

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

Comment 2

5 years ago
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
Blocks: 699351
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: HTML Frames
Ever confirmed: true
Keywords: regression
OS: Windows Server 2003 → All
Product: Firefox → Core
QA Contact: untriaged → layout.html-frames

Comment 3

5 years ago
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
Created attachment 608050 [details]
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.

Updated

5 years ago
tracking-firefox11: --- → ?
The new code depends on mInnerView's bounds being set correctly. Unfortunately, the width and height are 0,0 in this case.
Created attachment 608199 [details] [diff] [review]
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.
Assignee: nobody → roc
Attachment #608199 - Flags: review?(tnikkel)
status-firefox11: --- → affected
status-firefox12: --- → affected
status-firefox13: --- → affected
tracking-firefox12: --- → ?
tracking-firefox13: --- → ?
Comment on attachment 608199 [details] [diff] [review]
fix

Wonder why we didn't do it this way before.
Attachment #608199 - Flags: review?(tnikkel) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/4790b56fe677
https://hg.mozilla.org/mozilla-central/rev/4790b56fe677
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
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.
Attachment #608199 - Flags: approval-mozilla-esr10?
Attachment #608199 - Flags: approval-mozilla-beta?
Attachment #608199 - Flags: approval-mozilla-aurora?
Duplicate of this bug: 736952
(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.
(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?
tracking-firefox11: ? → +
tracking-firefox12: ? → +
tracking-firefox13: ? → +
Comment on attachment 608199 [details] [diff] [review]
fix

[Triage Comment]
Approved for Aurora 13 and Beta 12. This shouldn't affect the ESR10 though.
Attachment #608199 - Flags: approval-mozilla-esr10?
Attachment #608199 - Flags: approval-mozilla-esr10-
Attachment #608199 - Flags: approval-mozilla-beta?
Attachment #608199 - Flags: approval-mozilla-beta+
Attachment #608199 - Flags: approval-mozilla-aurora?
Attachment #608199 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-beta/rev/7f0430a6cad1
https://hg.mozilla.org/releases/mozilla-aurora/rev/e64001c17c65
status-firefox12: affected → fixed
status-firefox13: affected → fixed
status-firefox-esr10: --- → affected
tracking-firefox-esr10: --- → 12+
status-firefox-esr10: affected → unaffected
tracking-firefox-esr10: 12+ → ---
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.
(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

5 years ago
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.

Updated

5 years ago
Blocks: 739398
Duplicate of this bug: 739398
Duplicate of this bug: 739141
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.
Duplicate of this bug: 739141

Updated

5 years ago
Duplicate of this bug: 739423

Updated

5 years ago
No longer blocks: 739398

Updated

5 years ago
Duplicate of this bug: 689054

Updated

5 years ago
Summary: WYWSIWYG editor in mambo ceases to visualise following update to Firefox11. → WYWSIWYG editor in mambo ceases to visualise following update to Firefox11 (TinyMCE)

Comment 25

5 years ago
(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.
Whiteboard: [qa+]
Summary: WYWSIWYG editor in mambo ceases to visualise following update to Firefox11 (TinyMCE) → WYSIWYG editor in Mambo ceases to visualise following update to Firefox 11 (TinyMCE)
Maybe this should be added to "known issues" in Firefox 11 relnotes?

Updated

5 years ago
Flags: in-testsuite?
Created attachment 610751 [details]
testcase

Updated

5 years ago
Keywords: testcase
Duplicate of this bug: 743726

Comment 29

5 years ago
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.
status-firefox12: fixed → verified

Comment 30

5 years ago
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

Updated

5 years ago
Duplicate of this bug: 736518

Comment 32

5 years ago
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
status-firefox13: fixed → verified
Duplicate of this bug: 743980
You need to log in before you can comment on or make changes to this bug.