Open
Bug 1774860
Opened 2 years ago
dom/serviceworkers/test/test_error_reporting.html needs to be re-written for serviceworker_e10s
Categories
(Core :: DOM: Service Workers, task, P3)
Core
DOM: Service Workers
Tracking
()
NEW
People
(Reporter: asuth, Unassigned)
References
(Depends on 1 open bug)
Details
This came up in bug 1618072 but also is relevant in bug 1764761 (which is removing the cookie lifetime policy setting).
The general situation for the https://searchfox.org/mozilla-central/source/dom/serviceworkers/test/test_error_reporting.html test is:
- It's a normal mochitest that would listen for console message using SpecialPowers' mechanism for this.
- Console message related:
- Before serviceworker_e10s, all of these console messages would definitely be emitted in the content process the mochitest global was in.
- After serviceworker_e10s and especially after we started spawning ServiceWorkers in their own process, the console messages would be generated in the root parent process or the content process the ServiceWorker was spawned in. So we never see the console messages.
- We only were using the console messages as a means of checking our contract with devtools; the console messages were the contract and as a result we'd expect devtools to then show them. I'm not actually sure where we are on this. Bug 1429805 has the high level goal of related reporting, and bug 1441711 and related bugs maybe mean that devtools might actually still be getting error messages here even if the test is not.
- We should probably figure out how to mark bug 1429805 as fixed and have some in-tree docs for serviceworkers on how the console logging works; with that knowledge we can then decide whether to have a testing dependency on devtools for this and/or if we should update SpecialPowers' console magic to do so or otherwise approximate the behavior, because it does seem like a common testing desire to verify that devtools for the current window would have a specific error.
- Permission related:
- The tests involve when storage access was denied for ServiceWorker related things. Since the introduction of CookieJarSettings we have been latching storage access for a given window after the first check, so we can't mutate these things on the fly. We need to be creating iframes and/or this needs to be a "browser" test. A Browser test is probably the way to go for general sanity, as iframes introduce complexity and it usually only makes sense to stick with them for legacy reasons.
- The situation that's come up in bug 1764761 is that the cookie lifetime policy is being removed and the test was manipulating it on the fly just as an easy way to change what storage access checks would do. We should just be using storage permissions from the "browser" test.
You need to log in
before you can comment on or make changes to this bug.
Description
•