In this patch we actually have separate `Worker` and `Registration` components. All workers belonging to the same registration appear together under it.
{F2134654}
Note: I left the `Debug` button shown for every worker because sometimes we do have a target even though the worker might be waiting. I'm not sure when/how this happens, but I was able to debug it as well.
{F2134655}
BTW I found a quick –and more reliable? I seems I don't need to reload- way of testing this. **STR**:
- Start a local HTTP server at `mozilla-central/devtools/client/application/test/browser/resources/service-workers`
- Open `localhost:8080/simple.html` (or whatever the port) and open devtools there
- Open `localhost:8080/debug.html` (or whatever the port) and open devtools there
You should be able to see both workers under the same registration scope.
Differential Revision: https://phabricator.services.mozilla.com/D72173
As a result of the first part review and some testing, there were some issues re: repeating things among workers that actually belonged to the registration (the ID's for React keys, `Unregister` button, `Last updated` time…).
Initially I wanted to do the "grouping" of all the workers belonging to the same registration, but I think this is less confusing to use and test.
This patch initiates that work by renaming our `WorkerList` and `WorkerListEmpty` components to `Registration*`.
Differential Revision: https://phabricator.services.mozilla.com/D72172
In this patch we add a new resource type for page errors.
We don't do anything specific for CSS Warnings yet, as they're going
to be handled as part of Bug 1625910.
A test is added (following devtools/shared/webconsole/test/chrome/test_page_errors.html
as an example).
A couple function that were used for the console-messages test
are moved into head.js as they're also used in the error-message test.
Differential Revision: https://phabricator.services.mozilla.com/D71955
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
The only test we have is split in two tests, one for
checking the interactions with the inspector, and the
other one to check webconsole actions, like selecting
context and store as global variable context menu entry.
We add test cases to ensure the menu has the expected
structure and that the expected menu item are checked
when we expect to.
We add a helper function to be able to load a URI + iframes
so the setup is terser on the tests.
The id of the meun actually had to be fixed, as it was
the same as the console settings menu.
Depends on D71729
Differential Revision: https://phabricator.services.mozilla.com/D71731
Log the console replaced message only after the current batch of messages are consumed.
We also enable the timestamp in the test, so in case of failure we can diagnose
what's going on better.
Differential Revision: https://phabricator.services.mozilla.com/D72121