608718 - Firefox quoting messages twice on a forum running the TinyMCE editor

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Oskar Ivanić (:icecold)]

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.

Comment 1

[Oskar Ivanić (:icecold)]

Attachment: Example

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

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

Comment 3

[(no longer active)]

Confirming.  I created an account on the website, with the following info:

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

Comment 4

[Oskar Ivanić (:icecold)]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Oskar, that's great.  Could you please put the http urls from about:buildconfig for those builds in this bug?

Comment 6

[Oskar Ivanić (:icecold)]

Without quoting problem: http://hg.mozilla.org/mozilla-central/rev/f6e81dd5a125
With quoting problem: http://hg.mozilla.org/mozilla-central/rev/29c228a4d7eb

Comment 7

[(no longer active)]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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!

Comment 9

[(no longer active)]

Bisecting resulted in:

The first bad revision is:
changeset:   55803:29c228a4d7eb
user:        Johnny Stenback <[e-mail]>
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=[e-mail]. 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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[(no longer active)]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

> It did!

Which changeset was that, if I might ask?

Comment 13

[(no longer active)]

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.

Comment 14

[(no longer active)]

(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

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[(no longer active)]

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

Comment 17

[(no longer active)]

Bug 612276 which is blocking depends on this bug (and is probably a dupe of it).

Comment 18

[Oskar Ivanić (:icecold)]

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.

Comment 19

[Marek Raida]

I see similar problem in Confluence using TinyMCE as well, although different version...

Comment 20

[Robert Sayre]

(In reply to comment #17)
> Bug 612276 which is blocking depends on this bug (and is probably a dupe of
> it).

Assigning to Ehsan.

Comment 21

[(no longer active)]

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

Comment 22

[Robert Sayre]

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.

Comment 23

[(no longer active)]

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

Comment 24

[Damon Sicore (:damons)]

Who owns this?

Comment 25

[(no longer active)]

(In reply to comment #24)
> Who owns this?

It used to be assigned to sayrer, so I'll reassign it to him.

Comment 26

[Chris Leary [:cdleary] (not checking bugmail)]

Stealing assignment. I've got a sneaking suspicion this is regexp.

Comment 27

[Chris Leary [:cdleary] (not checking bugmail)]

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?

Comment 28

[Chris Leary [:cdleary] (not checking bugmail)]

(By the way, this confirmation would make this bug a duplicate of bug 605754.)

Comment 29

[Chris Leary [:cdleary] (not checking bugmail)]

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

Comment 30

[Oskar Ivanić (:icecold)]

Seems that this has been fixed in 20101203 build.
Quoting is now working normally on http://www.bug.hr/forum

Comment 31

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?