671221 - 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.

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Aslam]

Attachment: 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

Comment 1

[Tim (fmdeveloper)]

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.

Comment 2

[Aslam]

(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.

Comment 3

[Aslam]

(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

[Tim (fmdeveloper)]

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

Comment 5

[Aslam]

Attachment: Steps to reproduce the FF Issue

Comment 6

[Aslam]

(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.

Comment 7

[Aslam]

(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

[Tim (fmdeveloper)]

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?

Comment 9

[Aslam]

(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.

Comment 10

[Aslam]

(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

[Tim (fmdeveloper)]

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.

Comment 12

[Tim (fmdeveloper)]

Attachment: Zip of Saved Frame as Web Page Complete

Comment 13

[Tim (fmdeveloper)]

Attachment: Screenshot of layout in 3.6.18

Comment 14

[Tim (fmdeveloper)]

Attachment: Screenshot of layout in Nightly (8)

Comment 15

[Boris Zbarsky [:bzbarsky]]

Tim, can you hunt down a regression range?

Comment 16

[Tim (fmdeveloper)]

I'll give it a go

Comment 17

[Tim (fmdeveloper)]

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

Comment 18

[Boris Zbarsky [:bzbarsky]]

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 <[e-mail]>
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.

Comment 19

[Aslam]

(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 <[e-mail]>
> 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

Comment 20

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 21

[Aslam]

(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.

Comment 22

[Boris Zbarsky [:bzbarsky]]

> 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

[Spocke]

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.

Comment 24

[Boris Zbarsky [:bzbarsky]]

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

[Spocke]

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.

Comment 26

[Boris Zbarsky [:bzbarsky]]

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.

Comment 27

[Aslam]

(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!!!