Closed Bug 613960 Opened 10 years ago Closed 10 years ago
CKEditor toolbar customisation stopped working in recent nightlies
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
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.... :(
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.
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 <email@example.com> date: Wed Nov 10 18:34:44 2010 -0800 summary: Fix register allocation inside STRICTEQ (bug 610498, r=dmandelin).
10 years ago
Duplicate of this bug: 613764
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.
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.