This patch adds a test to ensure that a dedicated worker can be created
in a page which is controlled by a servcie worker.
Differential Revision: https://phabricator.services.mozilla.com/D132371
We should use the parititoned principal when creating clientSource in
WorkerPrivate if the workerPrivate is in third-party context.
Differential Revision: https://phabricator.services.mozilla.com/D132370
This patch enables partitioned service workers in third-party contexts.
Doesn't like before, we will allow service workers to be registered even
the third-party contexts don't have storage access and the registered
service workers will be partitioned by the top-level site.
You can control this by using the pref 'privacy.partition.serviceWorkers'.
Setting this to true will enable the partitioning, otherwise, it will
still use the old behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131788
Keeping the pref as signed, since the existing code explicitly handles that case, so someone may have -1 as the pref value.
Differential Revision: https://phabricator.services.mozilla.com/D132020
The query method already validates whether access to private cookies is
allowed. It cannot yield private cookies if not allowed, so checking it
again in the loop of getAll is redundant..
Differential Revision: https://phabricator.services.mozilla.com/D127644
Move the duplicate logic of parsing the storeId to a common place.
This patch has the following observable change in behavior:
- Invalid storeId (whether with the "firefox-container-" prefix or with
something else) have the same error message instead of distinct ones.
Instead of "Illegal storeId: X` or "Unknown storeId", the message is
now `Invalid cookie store id: "X"`, which is also what Chromium uses.
Differential Revision: https://phabricator.services.mozilla.com/D127643
The cookies API implementation emits a bunch of errors in some cases,
but these are not covered by unit tests. I'm going to refactor some
logic involving these checks, and before doing so I'd like to start
with unit tests with the current behavior as expectations.
Differential Revision: https://phabricator.services.mozilla.com/D127642
Test got added in bug 1728515. Code coverage seems too slow to reproduce the
condition which yields the timeout.
Depends on D132473
Differential Revision: https://phabricator.services.mozilla.com/D132474
It's only meaningfully read in two places:
* WebRender fallback code.
* Some widget DEBUG-only code, which on Linux is ifdef'd and on Windows does
some rather sketchy things like sleeping for 30ms
So I think it should be ok to remove, since WR fallback has its own flashing
pref as well, IIUC.
Differential Revision: https://phabricator.services.mozilla.com/D132313
Make `chrome/browser/content/browser/license.html` include the
WinToast license if the WDBA is enabled and never include the WinToast
license in `chrome/toolkit/content/global/license.html`.
While here, fix the anchor, which is case sensitive.
Differential Revision: https://phabricator.services.mozilla.com/D132421
We're using the new `force` parameter for `insertAnonymousContent` to force creating a container
for the anonymous content, and we add a new option to the CanvasAnonymousHelper so highlighter
can choose to not wait for the dom to load.
For now we only use it for the paused debugger overlay as the other highlighters might need
an inspector front, which may require the dom to be ready.
We enable the assertions in browser_dbg-paused-overlay-loading.js to check that the
highlighter is visible.
This required a few changes in the highlighter test actor.
First, it was waiting for an inspector front in its initialize method, which was
waiting indefinitely in our test as the document is paused. As this was only done
to retrieve the inspector actorID, we simply remove it and retrieve the actorID
through the connection and the target form when it's needed (for the eye dropper).
Secondly, the isPausedDebuggerOverlayVisible method was returning true even when
the highlighter wasn't displayed, so we check a few additional attributes.
Depends on D132034
Differential Revision: https://phabricator.services.mozilla.com/D132116
Even if landing bug 1697683, this NullPointerException occurs on the
background thread. So I would like to add more null check for this crash.
Differential Revision: https://phabricator.services.mozilla.com/D132329