We get many errors in that test on the Mac OS X tinderbox, example log: http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1287670908.1287672455.9700.gz Regression range for m-c: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b1b6968c3054 &tochange=0dd1aab31305 Regression range for c-c: http://hg.mozilla.org/comm-central/pushloghtml?fromchange=76cd83285f89 &tochange=92544eb8a854

The first failure in the test is chrome://mochitests/content/chrome/widget/tests/test_keycodes.xul | US 'a' [Command], wrong number of key events - got 0, expected 2 The patch from bug 591483 added a commandkey 'a' for the AddonManager, perhaps that's related?

It shouldn't be; the test calls preventDefault on the event.

I wonder if stefan can find some time to see if this is doing funky things on mac locally for him.

(In reply to comment #1) > The first failure in the test is > > chrome://mochitests/content/chrome/widget/tests/test_keycodes.xul | US 'a' > [Command], wrong number of key events - got 0, expected 2 Which is: testKey({layout:"US", keyCode:0, command:1, chars:"a", unmodifiedChars:"a"}, "a", SHOULD_DELIVER_KEYDOWN_KEYPRESS); This test opens the add-on manager in a new tab... then the rest fails. One (or more) of the other tests opens the help window (get 2 windows). If you comment out the above test everything goes fine.

If you remove the key added in bug 591483 all tests pass (I guess it's obvious, but jftr)

The only real difference I can see between bug 465090 (FF) and bug 591483 (SM) is that they use a capital "A" while we use a small "a". Stefan, can you check what happens if we also use "A" (addonsManagerCmd.commandkey in common/tasksOverlay.dtd)?

There's no difference, hmm.

jftr, this looks strange to me (but it doesn't matter in this case): tasksOverlay.xul <key id="key_addonsManager" key="&addonsManagerCmd.commandkey;" command="addonsmgr" modifiers="accel,shift"/> <menuitem id="addonsmgr" label="&addonsManagerCmd.label;" accesskey="&addonsManagerCmd.accesskey;" key="key_addonsManager" oncommand="toEM();"/>

Mass marking whiteboard:[orange] bugs WFM (to clean up TBPL bug suggestions) that: * Haven't changed in > 6months * Whose whiteboard contains none of the strings: {disabled,marked,random,fuzzy,todo,fails,failing,annotated,leave open,time-bomb} * Passed a (quick) manual inspection of bug summary/whiteboard to ensure they weren't a false positive. I've also gone through and searched for cases where the whiteboard wasn't labelled correctly after test disabling, by using attachment description & basic comment searches. However if the test for which this bug was about has in fact been disabled/annotated/..., please accept my apologies & reopen/mark the whiteboard appropriately so this doesn't get re-closed in the future (and please ping me via IRC or email so I can try to tweak the saved searches to avoid more edge cases). Sorry for the spam! Filter on: #FFA500