Closed Bug 1458046 Opened 6 years ago Closed 6 years ago

Intermittent browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - paste - Got true, expected false

Categories

(Firefox :: Toolbars and Customization, defect)

Product:
Firefox
Component:
Toolbars and Customization
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 66
Tracking Flags:
Tracking Status
firefox66 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: Gijs)

References

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell disabled][retriggered])

Attachments

(2 files)

Skipped test on mac
804 bytes, patch
jmaher
: review+
Details | Diff | Splinter Review
Bug 1458046 - avoid remote updates when the browser is not active and fix editcontrols_update test, r?NeilDeakin
47 bytes, text/x-phabricator-request
Details | Review
Filed by: aiakab [at] mozilla.com https://treeherder.mozilla.org/logviewer.html#?job_id=176300879&repo=autoland https://queue.taskcluster.net/v1/task/eoWFY3SzTgmouPhPEPPR7w/runs/0/artifacts/public/logs/live_backing.log INFO - Entering test bound test_init 10:09:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Clipboard has the given value: 'Sample' - 10:09:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is closed to begin with. - "closed" == "closed" - 10:09:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is open to begin with. - true == true - 10:09:28 INFO - Buffered messages logged at 10:09:28 10:09:28 INFO - Leaving test bound test_init 10:09:28 INFO - Entering test bound test_panelui_opened 10:09:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is closed to begin with. - "closed" == "closed" - 10:09:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - cut - 10:09:28 INFO - Buffered messages finished 10:09:28 INFO - TEST-UNEXPECTED-FAIL | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - paste - Got true, expected false 10:09:28 INFO - Stack trace: 10:09:28 INFO - chrome://mochikit/content/browser-test.js:test_is:1285 10:09:28 INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/browser_editcontrols_update.js:checkState:10 10:09:28 INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/browser_editcontrols_update.js:test_panelui_opened:67 10:09:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and selection changed - cut - 10:09:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and selection changed - paste - 10:09:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is open to begin with. - true == true -
Summary: Intermittent browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - paste - Got true, expected false → macOS TV (Verify) failure - browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - paste - Got true, expected false
This is a TV failure and the test hasn't been touched in a while, but I bet it still happens...
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
Status: REOPENED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → INCOMPLETE
Summary: macOS TV (Verify) failure - browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - paste - Got true, expected false → Intermittent browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - paste - Got true, expected false
https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
Status: REOPENED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → INCOMPLETE
This is still happening. Recent failure: https://treeherder.mozilla.org/logviewer.html#?job_id=204383606&repo=mozilla-inbound&lineNumber=1594 17:39:38 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - cut - 17:39:38 INFO - Buffered messages finished 17:39:38 INFO - TEST-UNEXPECTED-FAIL | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - paste - Got true, expected false 17:39:38 INFO - Stack trace: 17:39:38 INFO - chrome://mochikit/content/browser-test.js:test_is:1295 17:39:38 INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/browser_editcontrols_update.js:checkState:10 17:39:38 INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/browser_editcontrols_update.js:test_panelui_opened:67 17:39:38 INFO - chrome://mochikit/content/browser-test.js:Tester_execTest/<:1093 17:39:38 INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1084 17:39:38 INFO - chrome://mochikit/content/browser-test.js:nextTest/<:986 17:39:38 INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<:795 17:39:38 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and selection changed - cut - 17:39:38 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and selection changed - paste - 17:39:38 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is open to begin with. - true == true - 17:39:38 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and hidden - cut - 17:39:38 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and hidden - paste - 17:39:38 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel, hidden and selection changed - cut - 17:39:38 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel, hidden and selection changed - paste - 17:39:38 INFO - Leaving test bound test_panelui_opened
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
This bug failed 129 times in the last 7 days, failures occur on osx and macos nightly on debug and opt build types. Recent log: https://treeherder.mozilla.org/logviewer.html#?job_id=206259766&repo=mozilla-inbound&lineNumber=1607 INFO - TEST-OK | browser/components/customizableui/test/browser_947914_button_paste.js | took 1181ms 16:51:27 INFO - checking window state 16:51:27 INFO - TEST-START | browser/components/customizableui/test/browser_editcontrols_update.js 16:51:27 INFO - TEST-INFO | started process screencapture 16:51:28 INFO - TEST-INFO | screencapture: exit 0 16:51:28 INFO - Buffered messages logged at 16:51:27 16:51:28 INFO - Entering test bound test_init 16:51:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Clipboard has the given value: 'Sample' - 16:51:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is closed to begin with. - "closed" == "closed" - 16:51:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is open to begin with. - true == true - 16:51:28 INFO - Leaving test bound test_init 16:51:28 INFO - Entering test bound test_panelui_opened 16:51:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is closed to begin with. - "closed" == "closed" - 16:51:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - cut - 16:51:28 INFO - Buffered messages finished 16:51:28 INFO - TEST-UNEXPECTED-FAIL | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - paste - Got true, expected false 16:51:28 INFO - Stack trace: 16:51:28 INFO - chrome://mochikit/content/browser-test.js:test_is:1295 16:51:28 INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/browser_editcontrols_update.js:checkState:10 16:51:28 INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/browser_editcontrols_update.js:test_panelui_opened:67 16:51:28 INFO - chrome://mochikit/content/browser-test.js:Tester_execTest/<:1093 16:51:28 INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1084 16:51:28 INFO - chrome://mochikit/content/browser-test.js:nextTest/<:986 16:51:28 INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<:795 16:51:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and selection changed - cut - 16:51:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and selection changed - paste - 16:51:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is open to begin with. - true == true - 16:51:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and hidden - cut - 16:51:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and hidden - paste - 16:51:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel, hidden and selection changed - cut - 16:51:28 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel, hidden and selection changed - paste - 16:51:28 INFO - Leaving test bound test_panelui_opened Gijs : Can you please take a look at this bug?
Flags: needinfo?(gijskruitbosch+bugs)
Trying to narrow down when this regressed. Still working on that.
(In reply to Eliza Balazs [:ebalazs_] from comment #18) > Gijs: Hi, the retrigger and backfil result is: > > On this push > https://treeherder.mozilla.org/#/jobs?repo=mozilla- > inbound&searchStr=os%2Cx%2C10.10%2Copt%2Cmochitests%2Cwith%2Ce10s%2Ctest- > macosx64%2Fopt-mochitest-clipboard-e10s%2Cm- > e10s%28cl%29&revision=8f0aa41876197fc701ddadb73eee8edaa753af19 > the failure rate is over 50% so I think this is the culprit. > > Otherwise, this started somewhere in this range: > https://treeherder.mozilla.org/#/jobs?repo=mozilla- > inbound&searchStr=os%2Cx%2C10.10%2Copt%2Cmochitests%2Cwith%2Ce10s%2Ctest- > macosx64%2Fopt-mochitest-clipboard-e10s%2Cm- > e10s%28cl%29&tochange=8f0aa41876197fc701ddadb73eee8edaa753af19&fromchange=c19 > f84cb5fcbf896171350432d4476ba27d11d15&selectedJob=206558494 Based on that range, it looks to me like this is because of the switch to 8 content processes. Compare: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&searchStr=os%2Cx%2C10.10%2Copt%2Cmochitests%2Cwith%2Ce10s%2Ctest-macosx64%2Fopt-mochitest-clipboard-e10s%2Cm-e10s%28cl%29&selectedJob=206583725&revision=72e7ef77480d0845ceabb5d3747a5523db6bda9d and the preceding push: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&searchStr=os%2Cx%2C10.10%2Copt%2Cmochitests%2Cwith%2Ce10s%2Ctest-macosx64%2Fopt-mochitest-clipboard-e10s%2Cm-e10s%28cl%29&revision=c19f84cb5fcbf896171350432d4476ba27d11d15 The next question is "why"... It doesn't help that I've forgotten how/where we update edit controls on macOS. The edit menu's visibility update stuff is disabled on mac, so I think we just update it all the time, but I'm not clear on how/why. The failing bit of the test is basically: add_task(async function test_init() { // Put something on the clipboard to verify that the paste button is properly enabled during the test. let clipboardHelper = Cc["@mozilla.org/widget/clipboardhelper;1"].getService(Ci.nsIClipboardHelper); await new Promise(resolve => { SimpleTest.waitForClipboard("Sample", function() { clipboardHelper.copyString("Sample"); }, resolve); }); // Open and close the panel first so that it is fully initialized. await gCUITestUtils.openMainMenu(); await gCUITestUtils.hideMainMenu(); }); // Test updating when the panel is open with the edit-controls on the panel. // Updates should occur. add_task(async function test_panelui_opened() { gURLBar.focus(); gURLBar.value = "test"; await gCUITestUtils.openMainMenu(); checkState(false, "Update when edit-controls is on panel and visible"); //^^^^ fails because the paste command is disabled and is expected to be enabled, // because focus is in the URL bar (and looks like it is, looking at the // screenshots) and there should be something in the clipboard. // Note that there's another confusion here which is that the test expects the // cut command to be disabled, but I'd expect it to be enabled based on the fact // that in some screenshots, the text in the URL bar is selected as well (e.g. // https://taskcluster-artifacts.net/DNS68PqLQ5u5c_rfIFkgWg/0/public/test_info/mozilla-test-fail-screenshot_1x9OtU.png // from // https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&selectedJob=206583725&revision=72e7ef77480d0845ceabb5d3747a5523db6bda9d Maybe Neil or :erahm can shed light on this - perhaps the content process startup might be messing with the clipboard, or something? Or one of the preceding tests (for the cut/copy/paste buttons)?
Blocks: 1470280
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(erahm)
Flags: needinfo?(enndeakin)
(FWIW, I can't reproduce the failure locally, though I did notice other breakage caused by this broken querySelector call: https://searchfox.org/mozilla-central/rev/c56977420df7a1b692ce0f7e499ddb364d9fd7b2/browser/components/customizableui/test/browser_editcontrols_update.js#129 )
See Also: → 1487703
Based on the "see also" bug, maybe this has to do with updates sent from the child process and their timing.
This was retriggered and the culprit was found in Comment 18 and Comment 19. Thanks Gijs. Althought there is no reply to the ni, so I created this patch to disable the test.
Attachment #9018995 - Flags: review?(jmaher)
Comment on attachment 9018995 [details] [diff] [review] Skipped test on mac Review of attachment 9018995 [details] [diff] [review]: ----------------------------------------------------------------- thanks for keeping the verify here
Attachment #9018995 - Flags: review?(jmaher) → review+
Keywords: checkin-needed, leave-open
Whiteboard: [stockwell disable-recommended][retriggered] → [stockwell disabled][retriggered]
Pushed by ebalazs@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/74061c1b02a1 Disable browser_editcontrols_update.js on mac for frequent failures. r=jmaher
Keywords: checkin-needed
Unfortunately I don't know anything about this test or feature.
Flags: needinfo?(erahm)
(In reply to Eric Rahm [:erahm] from comment #28) > Unfortunately I don't know anything about this test or feature. Sure, but you wrote the patches on the regressing bug. Can you try to think of how those (ie more content processes) may have impacted focus/selection/clipboard behavior ?
Flags: needinfo?(erahm)
(In reply to :Gijs (he/him) from comment #29) > (In reply to Eric Rahm [:erahm] from comment #28) > > Unfortunately I don't know anything about this test or feature. > > Sure, but you wrote the patches on the regressing bug. Can you try to think > of how those (ie more content processes) may have impacted > focus/selection/clipboard behavior ? AFAICT by increasing the number of content processes we made various flaky tests more flaky, presumably by exacerbating existing e10s-related races due to doubling the probability of flakiness. I don't think this exposed any new faults.
Flags: needinfo?(erahm)
It looks like the commandupdate lock is still active while the test starts running and doesn't deactivate until a bit later. I added some debugging to https://treeherder.mozilla.org/#/jobs?repo=try&author=neil%40mozilla.com&selectedJob=207317011 The lock is only enabled at the beginning of tabbrowser's updateCurrentBrowser() at https://searchfox.org/mozilla-central/source/browser/base/content/tabbrowser.js#854 and unlocked when the tabswitch is complete at https://searchfox.org/mozilla-central/source/browser/modules/AsyncTabSwitcher.jsm#321 My understanding is that updateCurrentBrowser() is only called when tab switching occurs, and the previous tab browser_947914_button_paste.js opens a new tab, so perhaps something issn't waiting for the tab to open or close properly?
Flags: needinfo?(enndeakin)
(In reply to Neil Deakin from comment #31) > My understanding is that updateCurrentBrowser() is only called when tab > switching occurs, and the previous tab browser_947914_button_paste.js opens > a new tab, so perhaps something issn't waiting for the tab to open or close > properly? The paste test uses BTU.withNewTab(), which I guess we could update to wait for the relevant event... but that'd affect a lot of tests. Plus it'd mean we'd need to always be careful about any tests *preceding* tests that check command update state. Instead, is there a way for this test to check for the lock being present and/or an event when it is removed? That'd keep any sanity checks self-contained...
Flags: needinfo?(enndeakin)
You could always just call commandDispatcher.unlock() at the beginning of the test and see if that works to fix the test.
Flags: needinfo?(enndeakin)
(In reply to Neil Deakin from comment #33) > You could always just call commandDispatcher.unlock() at the beginning of > the test and see if that works to fix the test. It helps, but we end up with the same issues causing a later failure in fewer (but still trivially noticeable) cases: https://treeherder.mozilla.org/#/jobs?repo=try&revision=712a18230fb53cf2837d0cd7ceb323a5c5518ee2&selectedJob=208368981 07:06:11 INFO - Buffered messages logged at 07:06:11 07:06:11 INFO - Entering test bound test_init 07:06:11 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Clipboard has the given value: 'Sample' - 07:06:11 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is closed to begin with. - "closed" == "closed" - 07:06:11 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is open to begin with. - true == true - 07:06:11 INFO - Leaving test bound test_init 07:06:11 INFO - Entering test bound test_panelui_opened 07:06:11 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is closed to begin with. - "closed" == "closed" - 07:06:11 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - cut - 07:06:11 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - paste - 07:06:11 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and selection changed - cut - 07:06:11 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and selection changed - paste - 07:06:11 INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | The panel is open to begin with. - true == true - 07:06:11 INFO - Buffered messages finished 07:06:11 INFO - TEST-UNEXPECTED-FAIL | browser/components/customizableui/test/browser_editcontrols_update.js | unexpected update - 07:06:11 INFO - Stack trace: 07:06:11 INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/browser_editcontrols_update.js:isCommandEnabled:22 07:06:11 INFO - chrome://global/content/globalOverlay.js:goUpdateCommand:67 07:06:11 INFO - chrome://global/content/editMenuOverlay.js:goUpdateGlobalEditMenuItems:23 07:06:11 INFO - chrome://browser/content/browser.xul:oncommandupdate:1 07:06:11 INFO - chrome://global/content/bindings/browser.xml -> resource://gre/modules/RemoteController.js:enableDisableCommands:86 07:06:11 INFO - chrome://global/content/bindings/browser.xml:enableDisableCommandsRemoteOnly:1355 It would seem better to somehow wait to make sure all the remote-initiated command updates have completed. Is there no way to do this, even with a content task or something like that? Would it make sense to make one?
Flags: needinfo?(enndeakin)
In fact, maybe it would make sense to update the browser-test framework code that checks the window state between tests to ensure there's no tab switch/removal in flight. :mconley, is that easy to do?
Flags: needinfo?(mconley)
> In fact, maybe it would make sense to update the browser-test framework code > that checks the window state between tests to ensure there's no tab > switch/removal in flight. This would be more ideal. > It would seem better to somehow wait to make sure all the remote-initiated > command updates have completed. Is there no way to do this, even with a > content task or something like that? There isn't one, but you could add a check in RemoteController.js to ensure that the browser is document.activeElement before calling updateCommands and I'd expect that to avoid extraneous command updates.
Flags: needinfo?(enndeakin)
(In reply to Neil Deakin from comment #37) > There isn't one, but you could add a check in RemoteController.js to ensure > that the browser is document.activeElement before calling updateCommands and > I'd expect that to avoid extraneous command updates. Tried out this suggestion: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1a33a47f67579cb8cbdb7929ebfac4702e602dd4
(In reply to :Gijs (he/him) from comment #38) > (In reply to Neil Deakin from comment #37) > > There isn't one, but you could add a check in RemoteController.js to ensure > > that the browser is document.activeElement before calling updateCommands and > > I'd expect that to avoid extraneous command updates. > > Tried out this suggestion: > > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=1a33a47f67579cb8cbdb7929ebfac4702e602dd4 Doesn't look like it worked... did I misunderstand/misimplement the suggestion?
Flags: needinfo?(enndeakin)
(In reply to :Gijs (he/him) from comment #36) > In fact, maybe it would make sense to update the browser-test framework code > that checks the window state between tests to ensure there's no tab > switch/removal in flight. > > :mconley, is that easy to do? Sorry for the delay. It might be tempting to use the switchInProgress property on the AsyncTabSwitcher - however, that value becomes false as soon as the new tab that we're switching to is presented, and not when the AsyncTabSwitcher unlocks the command dispatcher and destroys itself. Maybe the easiest thing to do is to check for the presence of the AsyncTabSwitcher - perhaps by adding a method to tabbrowser.js that returns true if this._switcher is defined. If it is, you can then wait for the TabSwitchDone event, which (despite its name) fires when the AsyncTabSwitcher is about to destroy itself.
Flags: needinfo?(mconley)
> > https://treeherder.mozilla.org/#/ > > jobs?repo=try&revision=1a33a47f67579cb8cbdb7929ebfac4702e602dd4 > > Doesn't look like it worked... did I misunderstand/misimplement the > suggestion? The suggestion was intended to handle the errors mentioned in comment 35, but this latest run doesn't seem to include the changes you made there as well. As to checking the browser, the browser comparison and early return should perhaps more correctly go at the end to just where the commands are updated.
Flags: needinfo?(enndeakin)

(In reply to Neil Deakin from comment #41)

https://treeherder.mozilla.org/#/
jobs?repo=try&revision=1a33a47f67579cb8cbdb7929ebfac4702e602dd4

Doesn't look like it worked... did I misunderstand/misimplement the
suggestion?

The suggestion was intended to handle the errors mentioned in comment 35,
but this latest run doesn't seem to include the changes you made there as
well.

Oh, oops.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=88fc38b2378e9184f6dc04533cc77d29b3fd4f68

As to checking the browser, the browser comparison and early return should
perhaps more correctly go at the end to just where the commands are updated.

Annnnd I've just seen this. I assume this won't make a difference for the trypush for this test...

That trypush looks green enough, let's see about --verify: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ab0849a8b2799773d3c28f977f4bf182deede5e4 .

Assignee: nobody → gijskruitbosch+bugs
Status: REOPENED → ASSIGNED
Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/a643bdc1b7a4 avoid remote updates when the browser is not active and fix editcontrols_update test, r=NeilDeakin
Status: ASSIGNED → RESOLVED
Closed: 6 years ago → 6 years ago
status-firefox66: --- → fixed
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → Firefox 66
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: