Closed Bug 608718 Opened 10 years ago Closed 10 years ago

Firefox quoting messages twice on a forum running the TinyMCE editor

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta8+

People

(Reporter: icecold, Assigned: cdleary)

References

Details

(Keywords: regression, Whiteboard: [compartments])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101031 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101031 Firefox/4.0b8pre

This quoting problem started in nightly builds between 17 October and 18 October. 
When I want to quote on this forum (http://www.bug.hr/forum) post doubles.

They are using TinyMCE 3.3.9.2.

Reproducible: Always

Steps to Reproduce:
1.Go to http://www.bug.hr/forum (assuming that you're registered) .
2.Try to quote or edit post.
3.You will see that post doubles or messes up.
Actual Results:  
Post doubled

Expected Results:  
It should quote or edit fine.
Attached image Example
(In reply to comment #0)
> This quoting problem started in nightly builds between 17 October and 18
> October. 

i.e. http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bfe85b4ed5cd&tochange=cfd18201f49b
Can you verify that Range by checking about:buildconfig since I cannot reproduce due to that I'm not registered?
Component: General → Editor
Product: Firefox → Core
QA Contact: general → editor
Version: unspecified → Trunk
Keywords: regression
Confirming.  I created an account on the website, with the following info:

User name: testmozilla@mailinator.com
Password: ttlepu

This info can be used in bisecting the problem.  Note that in order to quote a post, you should click on the link reading "Citiraj" at the right side of the post.

Also, it may not be an editor problem, since the HTML that is pasted in the editor before TinyMCE is initialized looks like this:

<div class="editor_quote"><div class="editor_quote_header">ATiGamer kaže...</div><div class="editor_quote_content"><div class="editor_quote"><div class="editor_quote_header">ShadoW kaže...</div><div class="editor_quote_content"><div class="editor_quote"></div><p>Ali 69xx bi trebala imati 4 srednje pametna shadera umjesto 4 glupa i 1 pametni. Ako tako bude, to bi dosta moglo utjecati...</p></div></div><p>Prelazak s 4+1D na 4D arhitekturu nije toliko bitan što se teselacije tiče.</p><p>Puno bitniji je broj i raspored teselacijskih jedinica.</p></div></div><p><p�<div class="editor_quote"></p�<div></p><div class="editor_quote_header">ATiGamer kaže...</div><div class="editor_quote_content"><div class="editor_quote"><div class="editor_quote_header">ShadoW kaže...</div><div class="editor_quote_content"><div class="editor_quote"></div><p>Ali 69xx bi trebala imati 4 srednje pametna shadera umjesto 4 glupa i 1 pametni. Ako tako bude, to bi dosta moglo utjecati...</p></div></div><p>Prelazak s 4+1D na 4D arhitekturu nije toliko bitan što se teselacije tiče.</p><p><br></p></div><p></p>

Which looks to be corrupted already.
Status: UNCONFIRMED → NEW
Ever confirmed: true
blocking2.0: --- → ?
It's my first time finding regressions so it may not be very helpful but I downloaded builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
This one: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-10-13-04-mozilla-central/ is not having problems with quoting.
And this one: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-10-13-22-mozilla-central/ is having. If you want me to do more searching, please direct me to hourly builds for builds on that date.
Oskar, that's great.  Could you please put the http urls from about:buildconfig for those builds in this bug?
Regression range: <http://hg.mozilla.org/mozilla-central/pushloghtml?tochange=29c228a4d7eb&fromchange=f6e81dd5a125>.  Lots of stuff there.  I'll bisect the range, but it will probably be finished tomorrow.
Most of the lots of stuff is compartments landing; I'm not sure whether to be happy (that we found it) or sad (for obvious reasons) if the bug is in that marge.

Oskar, thank you very much for doing that work.  That was very helpful!
Summary: Firefox not quoting properly with TinyMCE editor → Firefox quoting messages twice on a forum running the TinyMCE editor
Bisecting resulted in:

The first bad revision is:
changeset:   55803:29c228a4d7eb
user:        Johnny Stenback <jst@mozilla.com>
date:        Wed Oct 13 18:40:15 2010 -0700
summary:     Bug 580128. Disable a few more browser-chrome tests that don't agree with compartments yet. r=mrbkap@gmail.com. CLOSED TREE

Which is the latest cset in the compartments merge <http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=29c228a4d7eb>.  This leads us to two conclusions:

1. This is caused by compartments.
2. hg bisect is broken across merges.  Bisecting the tracemonkey tree could lead to better results.
Assignee: nobody → general
Blocks: compartments
Component: Editor → JavaScript Engine
QA Contact: editor → general
> 2. hg bisect is broken across merges.

It's not, actually.  You just have to make sure the original bisection set includes a common ancestor of all the changesets on both sides of the merge.  

In any case, you should be able to bisect on the tm branch side of this using m-c; just mark that changeset as -b, test the first changeset in the tm merge (presumably ends up -g), and go from there.
(In reply to comment #10)
> > 2. hg bisect is broken across merges.
> 
> It's not, actually.  You just have to make sure the original bisection set
> includes a common ancestor of all the changesets on both sides of the merge.  

It did!

> In any case, you should be able to bisect on the tm branch side of this using
> m-c; just mark that changeset as -b, test the first changeset in the tm merge
> (presumably ends up -g), and go from there.

OK, bisecting that side now...
> It did!

Which changeset was that, if I might ask?
In trying to bisect the compartments range, Firefox failed to start with the assertion "compartment mismatched".  I skipped three times, with the same result, so I just gave up.  I'll leave this in the capable hands of our js hackers.
(In reply to comment #12)
> > It did!
> 
> Which changeset was that, if I might ask?

hg bis -r
hg bis -g f6e81dd5a125
hg bis -b 29c228a4d7eb
Ah.  See, f6e81dd5a125 is NOT an ancestor of the compartments changesets.  The closest common ancestor of f6e81dd5a125 and daa4c82b0a7a (which is the first changeset in the merge) is 6ff07c1f4dc2 (back on Oct 1 or so).  That's presumably the last m-c to t-m merge before this merge back....
(In reply to comment #15)
> Ah.  See, f6e81dd5a125 is NOT an ancestor of the compartments changesets.  The
> closest common ancestor of f6e81dd5a125 and daa4c82b0a7a (which is the first
> changeset in the merge) is 6ff07c1f4dc2 (back on Oct 1 or so).  That's
> presumably the last m-c to t-m merge before this merge back....

OK, that explains my bisect fail then!
Blocks: 611471
Blocks: 612276
Bug 612276 which is blocking depends on this bug (and is probably a dupe of it).
It seems that there is also problem with doubling (actually making more than three same posts) on WordPress, when I clicked on safe draft it made few same post in editor. Not sure if it's related to compartments.
blocking2.0: ? → beta8+
Whiteboard: [compartments]
I see similar problem in Confluence using TinyMCE as well, although different version...
(In reply to comment #17)
> Bug 612276 which is blocking depends on this bug (and is probably a dupe of
> it).

Assigning to Ehsan.
Assignee: general → ehsan
Component: JavaScript Engine → Editor
QA Contact: general → editor
Whiteboard: [compartments]
(In reply to comment #20)
> (In reply to comment #17)
> > Bug 612276 which is blocking depends on this bug (and is probably a dupe of
> > it).
> 
> Assigning to Ehsan.

How did we reach the conclusion that this is not a compartments problem?  Am I missing something?
Oops, sorry. I parsed your comment 17 incorrectly. You think this bug is causing bug 612276, not the other way around. Resetting. Sorry for the noise.
Assignee: ehsan → general
Component: Editor → JavaScript Engine
QA Contact: editor → general
Whiteboard: [compartments]
(In reply to comment #22)
> Oops, sorry. I parsed your comment 17 incorrectly. You think this bug is
> causing bug 612276, not the other way around. Resetting. Sorry for the noise.

Yes, that is indeed what I meant.  :-)

But if you need any help on the editor side, just ping me in IRC or here.
Who owns this?
(In reply to comment #24)
> Who owns this?

It used to be assigned to sayrer, so I'll reassign it to him.
Assignee: general → sayrer
Stealing assignment. I've got a sneaking suspicion this is regexp.
Assignee: sayrer → cdleary
Status: NEW → ASSIGNED
It doesn't repro with debug builds for me, but in my testing it looks like it's fixed after my most recent regexp changes: I saw the bad behavior on tracemonkey f20d22c4df47 and good on tracemonkey tip (past bdc3aa93dc26). Rob, could you confirm you see it as well?
(By the way, this confirmation would make this bug a duplicate of bug 605754.)
(In reply to comment #27)
> It doesn't repro with debug builds for me

Forgot to mention explicitly that it did repo in opt build, which is where I saw the transition from broken to fixed.
Seems that this has been fixed in 20101203 build.
Quoting is now working normally on http://www.bug.hr/forum
Are the patches that fix this only on tracemonkey, or are they also on mozilla-central?  Could you annotate the bug as fixed-in-tracemonkey or FIXED as appropriate?
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Duplicate of this bug: 616706
Duplicate of this bug: 613527
Blocks: 619449
You need to log in before you can comment on or make changes to this bug.