Closed Bug 613960 Opened 10 years ago Closed 10 years ago

CKEditor toolbar customisation stopped working in recent nightlies

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

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

People

(Reporter: bugzilla1, Assigned: dvander)

References

()

Details

(Keywords: regression, Whiteboard: fixed-in-tracemonkey)

Attachments

(2 files)

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?
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?
blocking2.0: --- → ?
(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...
Hah.  Yeah, no worries about that.  I wouldn't do that to anyone other than maybe Martijn.  ;)
OK, it broke sometime between the November 10 and 11 TM nightlies:

http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=2fd60328c2b0&tochange=3d63107fc788
Assignee: nobody → general
Component: Editor → JavaScript Engine
QA Contact: editor → general
Hmm.  I can't reproduce with a TM build from revision 3d63107fc788 (tested debug and opt both).
I've just double-checked on a different machine (both Win 7) and 3d63107fc788 is definitely showing the regression for me.
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....  :(
blocking2.0: ? → beta8+
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.
Blocks: 613437
Oh, this is great, it works fine when firebug is installed... :/
Interesting.  I do NOT have Firebug installed.
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).
Further bisection shows this is a regression from:

changeset:   57090:c938c2dc5f37
user:        David Anderson <danderson@mozilla.com>
date:        Wed Nov 10 18:34:44 2010 -0800
summary:     Fix register allocation inside STRICTEQ (bug 610498, r=dmandelin).
Duplicate of this bug: 613764
Attached patch fixSplinter Review
Assignee: general → dvander
Status: NEW → ASSIGNED
Attachment #492865 - Flags: review?(dmandelin)
Attachment #492865 - Flags: review?(dmandelin) → review+
Hmm.  So is the reason I couldn't reproduce that this was 32-bit only?
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.
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.
(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.
http://hg.mozilla.org/mozilla-central/rev/1829374e7d19
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.