Closed Bug 1315829 Opened 7 years ago Closed 5 years ago

Intermittent TEST-UNEXPECTED-TIMEOUT | toolkit/components/extensions/test/xpcshell/test_ext_runtime_onInstalled_and_onStartup.js | Test timed out


(WebExtensions :: General, defect, P2)



(firefox66 fixed)

Tracking Status
firefox66 --- fixed


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


(Blocks 2 open bugs)


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


(1 file)

Component: WebExtensions: Untriaged → WebExtensions: General
Priority: -- → P3
Closed: 6 years ago
Resolution: --- → INCOMPLETE
Resolution: INCOMPLETE → ---
Matt, for some reason, on Linux this is failing frequently on my 57-as-Beta uplift simulation pushes on Try. applied locally should suffice for reproducing the specific build configuration. Is there any chance you could take a look?
Flags: needinfo?(matthewjwein)
Matt is no longer working for Mozilla, I'll try to take a look today.
Flags: needinfo?(matthewjwein) → needinfo?(aswan)
I'm pretty certain that this is a test issue and not a product regression.  I looked at several logs and they are timing out in a bunch of different places, but all the ones that I looked at appeared to be at `await extension.awaitStartup()` calls following an extension or AddonManager restart.  Our extension wrappers track restarts by tracking a sequence of events that come from both the AddonManager and the webextension framework.  There's not necessarily a forced ordering between some of these events (eg between an extension Management ready or startup event and the corresponding AddonManager onInstalling and onInstalled events).  I suspect there's some sequence that causes the extension wrapper startup promise to not get properly set up.

I was also unable to reproduce this in a local run (though I didn't do all that many test runs).  Anyway, I think this should be fixable with some modest effort, but since it appears to just be a test issue, I think that work can be safely deferred until after we're done with pressing 57 work.
Flags: needinfo?(aswan)
FWIW, I intend to skip this test on Linux once 57 hits Beta because it's essentially permafailing on my uplift simulations in any regard. Not saying I disagree with the prioritization, but FYI.
There are lots of try failures here, but even with those excluded, this is quite frequent. Given comment 15 (thanks :aswan), I think I'll skip this.
Flags: needinfo?(gbrown)
Whiteboard: [stockwell needswork]
Pushed by
Skip xpcshell test_ext_runtime_onInstalled_and_onStartup.js for frequent intermittent failures; r=me,test-only
Flags: needinfo?(gbrown)
Keywords: leave-open
Whiteboard: [stockwell needswork] → [stockwell disabled]
Bulk priority update of open intermittent test failure bugs. 

P3 => P5
Priority: P3 → P5
This is skipped on all platforms, so should be treated as a high priority to re-enable. I'm going to make it a P2.
Priority: P5 → P2
Product: Toolkit → WebExtensions

I'm going to fix the test. The declarativeContent API (bug 1435864) is supposed to be called from the runtime.onInstalled event, and lack of test coverage for runtime.onInstalled may result in unwanted regressions.

Assignee: nobody → rob
Blocks: 1435864
Pushed by
Re-enable test_ext_runtime_onInstalled_and_onStartup.js r=aswan
Keywords: leave-open
Closed: 6 years ago5 years ago
Resolution: --- → FIXED
Whiteboard: [stockwell disabled] → [stockwell fixed]
Target Milestone: --- → mozilla66

Will QA validation be required for this bug?

Flags: needinfo?(rob)
Flags: needinfo?(rob) → qe-verify-
You need to log in before you can comment on or make changes to this bug.