Eden Chuang
81fff21b00
Several tests introspect workers through the nsIWorkerDebuggerManager -- by
enumerating it, matching a worker by its (relative) script URL, or checking
process placement. With the parent-process RemoteWorkerDebugger on by default a
worker registers its debugger in the parent process, which reports the absolute
script URL, registers asynchronously over IPC, and (for content workers) is no
longer visible in the content-process manager. These tests assume the local
WorkerDebugger's synchronous, content-process, relative-URL behaviour and fail.
Pin dom.worker.remoteDebugger.enabled to false in these tests so they keep using
the local WorkerDebugger. These checks are debugger-location-dependent: the
legacy worker-introspection path still needs to be modernized to the
RemoteWorkerDebugger model, and each pin (or test) should be removed once the
local WorkerDebugger mechanism is removed:
- devtools/client/shared/test/browser_dbg_listworkers.js
- devtools/shared/webconsole/test/chrome/test_console_worker.html
- devtools/shared/webconsole/test/chrome/test_jsterm_autocomplete.html
- dom/workers/test/test_shutdownCheck.xhtml
- dom/workers/test/browser_privilegedmozilla_remoteworker.js
- dom/workers/test/browser_serviceworker_fetch_new_process.js
- dom/base/crashtests/eventSource_invalid_scheme_worker_shutdown.html
- toolkit/components/extensions/test/browser/browser_ext_background_serviceworker.js
The extension service-worker xpcshell helper (head_service_worker.js) is instead
updated to watch the parent-process WorkerDebuggerManager when the pref is on, so
test_ext_background_service_worker keeps working through the remote debugger
rather than being pinned.
dom_worker_helper.js matches a debugger by absolute or relative script URL (the
parent reports the absolute URL), and test_WorkerDebugger.xhtml only asserts
nsIWorkerDebugger.window for the local debugger, since a remote worker has no
window in the parent process.
Run the worker tests that exercise worker debugging under both pref values, so
both the local WorkerDebugger and the parent-process RemoteWorkerDebugger stay
covered on CI regardless of the channel default. dom_worker_helper.js gains an
addTaskWithBothWorkerDebuggers helper, and each of the following runs once with
dom.worker.remoteDebugger.enabled=false and once with it true:
- the WorkerDebugger* / WorkerDebuggerGlobalScope* chrome mochitests (except
test_WorkerDebugger_frozen.xhtml)
- dom/workers/test/browser_WorkerDebugger{,_waiting}.initialize.js
- devtools browser_worker_tracer.js and browser_target_command_tab_workers.js
- the WebDriver BiDi browser_WorkerListener_{chromeWorker,serviceWorker,
sharedWorker}.js tests
A few worker tests keep global state that does not reset cleanly between the two
runs -- browser_target_command_browser_workers.js enumerates every worker in the
browser and its parent-process workers linger, test_WorkerDebugger_frozen.xhtml
manipulates frozen/suspended state, and browser_WorkerListener.js drives multiple
tabs -- so they keep running at the channel default rather than twice.
Add tests covering the parent-process worker debugging that the
RemoteWorkerDebugger enables:
- browser_parent_worker_nested.js: a chrome worker and the nested worker it
spawns both register through the parent-process RemoteWorkerDebugger, and the
nested worker's debugger URL is resolved to an absolute URL.
- browser_resources_thread_states_parent_worker.js: THREAD_STATE resources let
DevTools interactively pause and resume a chrome worker via main-process
(Browser Toolbox) commands.
Differential Revision: https://phabricator.services.mozilla.com/D306652
3 lines
56 B
JavaScript
3 lines
56 B
JavaScript
"use strict";
|
|
self.postMessage("nested worker loaded");
|