Open Bug 1361484 Opened 3 years ago Updated 4 months ago
_tabswitch _updatecommands .js | only one command update per tab switch - Got 2, expected 1
This is not failing frequently enough to be directly actionable. It seems the failures happen only on debug builds so we could disable the test there if the intermittent failures become a problem, but I would like to know what causes this. The attached patch changes the test to dump the stack in the test log. Many runs on try didn't trigger the failure, but at least I'm now confident this patch isn't breaking the test: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9b4bf8f24f7f30cf4f9d2443c27d8f561104be2d
Attachment #8939591 - Flags: review?(enndeakin)
Attachment #8939591 - Flags: review?(enndeakin) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/76ea46e168ca make browser_tabswitch_updatecommands.js dump the stacks when there are more command updates than expected, r=Enn.
(In reply to OrangeFactor Robot from comment #34) The 2 stacks in the log for this failure are: Update stack: finish@chrome://browser/content/tabbrowser.xml:4537:15 postActions@chrome://browser/content/tabbrowser.xml:4832:17 handleEvent@chrome://browser/content/tabbrowser.xml:5192:15 EventListener.handleEvent*init@chrome://browser/content/tabbrowser.xml:4463:15 _getSwitcher@chrome://browser/content/tabbrowser.xml:5322:11 set_selectedIndex@chrome://browser/content/tabbrowser.xml:8574:11 set_selectedPanel@chrome://global/content/bindings/tabbox.xml:692:13 set_selectedIndex@chrome://global/content/bindings/tabbox.xml:398:15 set_selectedItem@chrome://global/content/bindings/tabbox.xml:430:34 set_selectedTab@chrome://global/content/bindings/tabbox.xml:100:15 set_selectedTab@chrome://browser/content/tabbrowser.xml:3932:11 switchTab@resource://testing-common/BrowserTestUtils.jsm:238:7 @chrome://mochitests/content/browser/browser/base/content/test/tabs/browser_tabswitch_updatecommands.js:14:9 Async*Tester_execTest/<@chrome://mochikit/content/browser-test.js:1065:21 TaskImpl_run@resource://gre/modules/Task.jsm:331:42 TaskImpl@resource://gre/modules/Task.jsm:280:3 asyncFunction@resource://gre/modules/Task.jsm:252:14 Task_spawn@resource://gre/modules/Task.jsm:166:12 Tester_execTest@chrome://mochikit/content/browser-test.js:1056:9 Tester.prototype.nextTest</<@chrome://mochikit/content/browser-test.js:956:9 SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:795:59 Update stack: enableDisableCommands@chrome://global/content/bindings/remote-browser.xml -> resource://gre/modules/RemoteController.js:91:5 enableDisableCommands@chrome://global/content/bindings/remote-browser.xml:571:13
It's looks likely that this is just some message from the child process that happens to get delayed long enough to get received after the command dispatching lock has been turned off. This isn't a concern as the feature is just an optimization. If the test failure is problematic we could just check for this specific case, but with now only one failure per week this doesn't seem too important.
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.