613960 - CKEditor toolbar customisation stopped working in recent nightlies

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Doug Wright]

STR

1) Visit http://ckeditor.com/demo
2) Click 'Custom toolbar'

Expected: The first editor instance on that page contains only a few buttons.
Actual: It has a full 3-row toolbar, like the instance below it.

This was working last week - bug 612447?

Comment 1

[Doug Wright]

Regression window is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ad227939db82&tochange=789f0f85f75a .

Comment 2

[Boris Zbarsky [:bzbarsky]]

Hmm.  Doug, there are no editor changes in that window, but there _is_ a giant TM merge.  Would you be willing to hunt down the regression range on the TM branch?

Comment 3

[Doug Wright]

(In reply to comment #2)
> Hmm.  Doug, there are no editor changes in that window, but there _is_ a giant
> TM merge.  Would you be willing to hunt down the regression range on the TM
> branch?

Sure - just don't ask me to turn CKEditor into a reduced testcase...

Comment 4

[Boris Zbarsky [:bzbarsky]]

Hah.  Yeah, no worries about that.  I wouldn't do that to anyone other than maybe Martijn.  ;)

Comment 5

[Doug Wright]

OK, it broke sometime between the November 10 and 11 TM nightlies:

http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=2fd60328c2b0&tochange=3d63107fc788

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hmm.  I can't reproduce with a TM build from revision 3d63107fc788 (tested debug and opt both).

Comment 7

[Doug Wright]

Attachment: Screenshots from either side of regression range

I've just double-checked on a different machine (both Win 7) and 3d63107fc788 is definitely showing the regression for me.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Hmm.  This is interesting.

It seems that I can't reproduce the bug at all on Mac (e.g. worksforme in latest m-c nightly with a clean profile).  So this might be Windows-specific....  :(

Comment 9

[(no longer active)]

Bug 613437 might also be related here.  We've lost 38 points on the selection tests in the richtext2 browserscope test suite in this TM merge.  Setting a dependency for now.

Comment 10

[Nochum Sossonko [:Natch]]

Oh, this is great, it works fine when firebug is installed... :/

Comment 11

[Boris Zbarsky [:bzbarsky]]

Interesting.  I do NOT have Firebug installed.

Comment 12

[Nochum Sossonko [:Natch]]

In my tests it seems that the config is incorrect, the end-result toolbar config for the basic editor is "Full" when it is supposed to be "Basic". I can't really figure anything else beyond that.

These values can be seen on CKEDITOR.instances.<instance name>.config.toolbar

where for <instance name> you would use the actual instance name (in our case 'editor2' for the basic editor).

Comment 13

[David Mandelin [:dmandelin]]

Further bisection shows this is a regression from:

changeset:   57090:c938c2dc5f37
user:        David Anderson <[e-mail]>
date:        Wed Nov 10 18:34:44 2010 -0800
summary:     Fix register allocation inside STRICTEQ (bug 610498, r=dmandelin).

Comment 15

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: fix

Comment 16

[David Anderson [:dvander] - inactive, e-mail if emergency]

http://hg.mozilla.org/tracemonkey/rev/1829374e7d19

Comment 17

[Boris Zbarsky [:bzbarsky]]

Hmm.  So is the reason I couldn't reproduce that this was 32-bit only?

Comment 18

[David Anderson [:dvander] - inactive, e-mail if emergency]

For all intents and purposes yeah. It's a bug on all platforms but x64 has so many registers that it would be really rare to see it.

Comment 19

[Nochum Sossonko [:Natch]]

OOC, how did you guys narrow down the problem here? More precisely, I was looking for a way to follow an object's value from its creation time through every modification (I was using getters and setters but wasn't able to capture the creation time/call). I know there's "watch" but I haven't been able to really get it to work before the object was actually created (i.e. to monitor the creation and then modification). Is there some other trick or debugging tool available?

Thanks.

Comment 20

[David Anderson [:dvander] - inactive, e-mail if emergency]

(In reply to comment #19)

Once Dave Mandelin had bisected to the problematic changeset, it was just a matter of stepping through the changed code in GDB. If it's hard to find a regression range then usually I try reducing the site's JavaScript or inserting alert/dump commands to narrow down where behavior diverges. This one would have been super tough to nail down that way, I suspect.

Comment 21

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/1829374e7d19