In FireFox 4.0 and above versions, textarea's with TinyMCE doesn't paint properly. Multiple span's are created where only 1 span should have been created, breaking down the entire layout of the Web Form.

RESOLVED INVALID

Status

()

Core
DOM: Core & HTML
RESOLVED INVALID
7 years ago
7 years ago

People

(Reporter: Aslam, Unassigned)

Tracking

Trunk
All
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

7 years ago
Created attachment 545633 [details]
TinyMCE.bmp

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0.1) Gecko/20100101 Firefox/5.0.1
Build ID: 20110707182747

Steps to reproduce:

I have a form with multiple elements like text boxes and text area's. 
I used TinyMCE for text area to get the toolbar actions for text area's.



Actual results:

It was working fine in FireFox 3.0, but when I upgraded to FireFox 4.0 the entire layout breaks.



Expected results:

After upgrade also, all the text area's should have been rendered properly with the toolbar options of TinyMCE
(Reporter)

Updated

7 years ago
Version: 5 Branch → 4.0 Branch

Comment 1

7 years ago
Does the issue still occur if you start Firefox in Safe Mode? http://support.mozilla.com/en-US/kb/Safe+Mode

How about with a new, empty profile? http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_8-make-a-new-profile

Please provide a public URL or reduced test case that exhibits this issue.
(Reporter)

Comment 2

7 years ago
(In reply to comment #0)
> Created attachment 545633 [details]
> TinyMCE.bmp
> 
> User Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0.1) Gecko/20100101
> Firefox/5.0.1
> Build ID: 20110707182747
> 
> Steps to reproduce:
> 
> I have a form with multiple elements like text boxes and text area's. 
> I used TinyMCE for text area to get the toolbar actions for text area's.
> 
> 
> 
> Actual results:
> 
> It was working fine in FireFox 3.0, but when I upgraded to FireFox 4.0 the
> entire layout breaks.
> 
> 
> 
> Expected results:
> 
> After upgrade also, all the text area's should have been rendered properly
> with the toolbar options of TinyMCE

Yes it is still reproducible in the Safe Mode as well.
(Reporter)

Comment 3

7 years ago
(In reply to comment #1)
> Does the issue still occur if you start Firefox in Safe Mode?
> http://support.mozilla.com/en-US/kb/Safe+Mode
> 
> How about with a new, empty profile?
> http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_8-make-a-new-
> profile
> 
> Please provide a public URL or reduced test case that exhibits this issue.

Yes it is still reproducible in the Safe Mode as well.

Comment 4

7 years ago
Please provide a public URL or reduced test case that exhibits this issue.
(Reporter)

Comment 5

7 years ago
Created attachment 546465 [details]
Steps to reproduce the FF Issue
(Reporter)

Comment 6

7 years ago
(In reply to comment #4)
> Please provide a public URL or reduced test case that exhibits this issue.

Please find the url specified in the txt and the steps to reproduce it.
(Reporter)

Comment 7

7 years ago
(In reply to comment #6)
> (In reply to comment #4)
> > Please provide a public URL or reduced test case that exhibits this issue.
> 
> Please find the url specified in the txt and the steps to reproduce it.

Any Update on the issue..

Comment 8

7 years ago
STR (from attachment)

1) Go to the following url -  
http://cs.digite.com/digite

2) Login with the following credentials - 
User Name - FFIssue
Password - 111111

3) After Login, Click on Open Items under Inbox Summary.

4) Click the item with the ID - "Def1" in the listing.

5) You can see, this is a HTML form with various form elements like Text Box, Text Area etc. 
Earlier, before upgrading to FF4 this was working fine. 
However after upgrading, the entire form's layout is crashed.

6) In one of the fields, we have used TinyMCE's toolbar, which in this case comes above all the elements in the form.

--------------------

Currently getting a 503 - Service Temporarily Unavailable with that URL. Is there another URL we can try?
(Reporter)

Comment 9

7 years ago
(In reply to comment #8)
> 
> Currently getting a 503 - Service Temporarily Unavailable with that URL. Is
> there another URL we can try?

I apologize for the inconvenience. This was because our was down on Sunday.
However this would be working now. Please check it again. 
And can you please give me an insight about the progress of the issue.
(Reporter)

Comment 10

7 years ago
(In reply to comment #8)
> STR (from attachment)

1) Go to the following url -  
> http://cs.digite.com/digite

2) Login with the following credentials - 
User
> Name - FFIssue
Password - 111111

3) After Login, Click on Open Items under
> Inbox Summary.

4) Click the item with the ID - "Def1" in the listing.

5)
> You can see, this is a HTML form with various form elements like Text Box,
> Text Area etc. 
Earlier, before upgrading to FF4 this was working fine. 
> However after upgrading, the entire form's layout is crashed.

6) In one of
> the fields, we have used TinyMCE's toolbar, which in this case comes above
> all the elements in the form.

--------------------

Currently getting a 503
> - Service Temporarily Unavailable with that URL. Is there another URL we can
> try?

Any update on the issue.

Comment 11

7 years ago
Updated STR

1) Go to the following url - http://cs.digite.com/digite

2) Login with the following credentials - 
User Name - FFIssue
Password - 111111

3) After Login, Click on Past Due Items under Inbox Summary.

4) Click the item with the ID - "Def1" in the listing.

5) You can see, this is a HTML form with various form elements like Text Box, Text Area etc. 
Earlier, before upgrading to FF4 this was working fine. 
However after upgrading, the entire form's layout is crashed.

6) In one of the fields, we have used TinyMCE's toolbar, which in this case comes above all the elements in the form.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: 4.0 Branch → 8 Branch

Comment 12

7 years ago
Created attachment 551294 [details]
Zip of Saved Frame as Web Page Complete

Comment 13

7 years ago
Created attachment 551295 [details]
Screenshot of layout in 3.6.18

Comment 14

7 years ago
Created attachment 551296 [details]
Screenshot of layout in Nightly (8)

Updated

7 years ago
Attachment #551295 - Attachment description: Screenshot of layout it 3.6.18 → Screenshot of layout in 3.6.18
Tim, can you hunt down a regression range?

Comment 16

7 years ago
I'll give it a go

Comment 17

7 years ago
Boris -> Here's what I came up with

Last good nightly: 2010-09-14
First bad nightly: 2010-09-15

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5588c9796f0b&tochange=0caec4ddff74
Hmm.  So in this case MCE is creating a totally different DOM in current trunk and 3.6.  In the former, it puts all the text inside a designmode iframe.

Tim, thanks for finding the regression range.  I bisected from there, and the behavior changed with:

The first bad revision is:
changeset:   53883:9405497abe4e
user:        Mounir Lamouri <mounir.lamouri@gmail.com>
date:        Wed Sep 15 09:54:20 2010 +0200
summary:     Bug 595429 - Add name IDL attribute for HTMLFieldSetElement. r=smaug a=jst

I suspect this is a bug in either TinyMCE or the site's use of it, but ccing Mounir just to make sure.
Component: Layout → DOM: Core & HTML
QA Contact: layout → general
Version: 8 Branch → Trunk
(Reporter)

Comment 19

7 years ago
(In reply to Boris Zbarsky (:bz) from comment #18)
> Hmm.  So in this case MCE is creating a totally different DOM in current
> trunk and 3.6.  In the former, it puts all the text inside a designmode
> iframe.
> 
> Tim, thanks for finding the regression range.  I bisected from there, and
> the behavior changed with:
> 
> The first bad revision is:
> changeset:   53883:9405497abe4e
> user:        Mounir Lamouri <mounir.lamouri@gmail.com>
> date:        Wed Sep 15 09:54:20 2010 +0200
> summary:     Bug 595429 - Add name IDL attribute for HTMLFieldSetElement.
> r=smaug a=jst
> 
> I suspect this is a bug in either TinyMCE or the site's use of it, but ccing
> Mounir just to make sure.

Hi Boris,
I had a chat with the TintMCE team and they said this is purely a FireFox bug. 
And secondly, this issue occurred only after I upgraded to FireFox 4.0.

Please help me out of this.

Regards,
Aslam

Regards,
Aslam
> and they said this is purely a FireFox bug. 

Did they say what the issue was, exactly?  From our point of view, we added a 'name' attribute on <fieldset> elements, and suddenly the TinyMCE code on the page is doing wildly different things than it used to do.... That sure doesn't sound like a bug in Firefox, past the fact that we added the attribute in the first place, which is required by the HTML5 spec.

> And secondly, this issue occurred only after I upgraded to FireFox 4.0.

Well, yes, because previous versions did not have a 'name' attribute on <fieldset>s.
(Reporter)

Comment 21

7 years ago
(In reply to Boris Zbarsky (:bz) from comment #20)
> > and they said this is purely a FireFox bug. 
> 
> Did they say what the issue was, exactly?  From our point of view, we added
> a 'name' attribute on <fieldset> elements, and suddenly the TinyMCE code on
> the page is doing wildly different things than it used to do.... That sure
> doesn't sound like a bug in Firefox, past the fact that we added the
> attribute in the first place, which is required by the HTML5 spec.
> 
> > And secondly, this issue occurred only after I upgraded to FireFox 4.0.
> 
> Well, yes, because previous versions did not have a 'name' attribute on
> <fieldset>s.

I checked on FF 6 also, this is reproducible. And i took the latest Tiny MCE jar also. then also it is reproducible.
When you add the name attribute on fieldsets, what does it makes the Tiny MCE code to disturb the DOM. Can u please elaborate, so that I can communicate the same to TINY MCE team.
> what does it makes the Tiny MCE code to disturb the DOM.

I have no idea.  That depends on what the Tiny MCE code is doing.

All that changed on our end is that fieldset.name now returns the same thing as fieldset.getAttribute("name") instead of returning undefined, setting fieldset.name does the same thing as fieldset.setAttribute("name", something), and |"name" in fieldset| now tests true instead of false.

Which of those things is confusing TinyMCE I have no idea.

The simplest thing would be for one of the TinyMCE developers to just cc themselves on this bug so I can talk to them directly.

I tried reporting this issue to them at http://www.tinymce.com/develop/bugtracker_view.php?id=4686 and we'll see how it goes.

Comment 23

7 years ago
This seems to be some form of implementation bug remove the extra comma from:
elements : 'clob1,',

So it becomes:
elements : 'clob1',

In the TinyMCE init call.

Having the extra comma there will then match all elements with a name that is "" and the fieldsets are now part of the elements collection of the form so it will swap the fieldsets with editors.
Spocke, thank you for looking into this!

Fieldsets have always been part of the elements collection of the form.  Try this testcase:

  <!DOCTYPE html>
  <body><form><fieldset></fieldset></form>
  <script>alert(document.forms[0].elements[0])</script>

It alerts the fieldset element in all Gecko versions back to at least Firefox 2.0.

So it sounds like the real change is in whether the predicate 'a name that is ""' matches the fieldset.  Can you possibly point me to the TinyMCE code that implements that matching algorithm?

That said, it sounds like there's just a bug in the way the digite.com page is using TinyMCE...

Comment 25

7 years ago
It's the extra comma in combination with the recent change to expose the name property for fieldsets that is causing the bug.

Checked the code and it uses the name property of the form elements to match it against the names in the elements option. So a extra "," will produce an empty string and that name will match the element now since I use element.name === name and it didn't before since it was undefined.
Aha, use of === makes it clear why the behavior changed.  Again, thank you!

Marking invalid, since this is a bug in the digite.com script, not in either our code or TinyMCE.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
(Reporter)

Comment 27

7 years ago
(In reply to Boris Zbarsky (:bz) from comment #26)
> Aha, use of === makes it clear why the behavior changed.  Again, thank you!
> 
> Marking invalid, since this is a bug in the digite.com script, not in either
> our code or TinyMCE.

Thanks a lot guyz.. 
The issue is resolved with that "," removed from the elements property or either giving a name property to the fieldset.
This has been a long pending issue.
Again thanking u guyz for helping me out with this.

Cheers!!!
You need to log in before you can comment on or make changes to this bug.