This introduces a boolean on nsCSPPolicy / nsIContentSecurityPolicy /
Document that is initially false and only set to true after a
REQUIRE_TRUSTED_TYPES_FOR_DIRECTIVE directive is associated to the
object. This provides fast check and early return when such a directive
is absent:
- TrustedTypeUtils's GetTrustedTypesCompliantString(), currently used by
Element::SetInnertHTML() and Element::InsertAdjacentHTML().
- nsCSPPolicy::AreTrustedTypesForSinkGroupRequired() currently used by
ShouldSinkTypeMismatchViolationBeBlockedByCSP() and
DoesSinkTypeRequireTrustedTypes().
This also makes nsCSPPolicy::hasDirective() fast for
nsIContentSecurityPolicy::REQUIRE_TRUSTED_TYPES_FOR_DIRECTIVE.
Differential Revision: https://phabricator.services.mozilla.com/D226882
Add autocorrect flag to `InputContext` to handle this by widget.
Since autocorrect is on-by-default, `mAutocorrect` is true by constructor.
But, I would like off-by-default in Chrome. Since Chrome UI may not want to
enable autocorrect by default such as bug 1881783.
Differential Revision: https://phabricator.services.mozilla.com/D221571
This patch introduces an explicit concept of lifetimes with mechanisms
in place so that actions taken by Clients (windows or non-ServiceWorker
orkers) will extend the lifetime of a ServiceWorker, but a ServiceWorker
cannot extend the life of another ServiceWorker.
The areas of concern are:
- ServiceWorker.postMessage: With ServiceWorkers exposed on workers and
the ability to access other registrations via ServiceWorkerContainer
being exposed, ServiceWorkers can message other ServiceWorkers. It's
essential that they never be allowed to give a ServiceWorker a
lifetime longer than their own.
- ServiceWorkerRegistration.update(): Requesting an update of a
registration should not allow any installed/updated ServiceWorker to
have a lifetime longer than the ServiceWorker creating the request.
- ServiceWorkerContainer.register(): Requesting the installation of a
new ServiceWorker should likewise constrain the lifetime of the newly
installed ServiceWorker.
Note that in cases where we would potentially spawn a ServiceWorker,
whether it be in response to postMessage or as part of an install or
update, a key criteria is whether the lifetime extends far enough into
the future for us to believe the ServiceWorker can accomplish anything.
Currently we have a constant of 5 seconds against a normal full
lifetime of 30 seconds (before 30 second grace period). So once a SW
has < 5 seconds of lifetime left, it won't be able to spawn a SW. Note
that in the case of install/update, we do not prevent the creation of
the job at this time, instead the job will fail during the check script
evaluation step as failure to spawn the ServiceWorker is equivalent to
a script load failure.
A somewhat ugly part of this implementation is that because Bug 1853706
is not yet implemented, our actors that are fundamentally associated
with a global don't have an inherent understanding of their relationship
to that global. So we approximate that by:
- For postMessage, we always have a ServiceWorkerDescriptor if we are
being messaged by a ServiceWorker, allowing us direct lookup.
- ServiceWorkerRegistration.update(): In a previous patch in the stack
we had ServiceWorkerRegistrationProxy latch the ClientInfo of its
owning global when it was created. Note that in the case of a
ServiceWorker's own registration, this will be created at startup
before the worker hits the execution ready state.
- Note that because we have at most one live
ServiceWorkerRegistration per global at a time, and the
registration is fundamentally associated with the
ServiceWorkerGlobalScope, that registration and its proxy will
remain alive for the duration of the global.
- ServiceWorkerContainer.register(): We already were sending the client
info along with the register call (as well as all other calls on the
container).
Looking up the ServiceWorker from its client is not something that was
really intended. This is further complicated by ServiceWorkerManager
being authoritative for ServiceWorkers on the parent process main thread
whereas the ClientManagerService is authoritative on PBackground and
actor-centric, making sketchy multi-threaded maps not really an option.
Looking up the ServiceWorker from a ServiceWorkerDescriptor is intended,
but the primary intent in those cases is so that the recipient of such a
descriptor can easily create a ServiceWorker instance that is
live-updating (by way of its owning ServiceWorkerRegistration; we don't
have IPC actors directly for ServiceWorkers, just the registration).
Adding the descriptor to clients until Bug 1853706 is implemented would
be an exceedingly ugly workaround because it would greatly complicate
the existing plumbing code, and a lot of the code is confusing enough
as-is.
This patch initially adopted an approach of encoding the scope of a
ServiceWorker as its client URL, but it turns out web extension
ServiceWorker support (reasonably) assumed the URL would be the script
URL so the original behavior was restored and when performing our
lookup we just check all registrations associated with the given
origin. This is okay because register and update calls are inherently
expensive, rare operations and the overhead of the additional checks is
marginal. Additionally, we can remove this logic once Bug 1853706 is
implemented.
As part of that initial scope tunneling was that, as noted above, we
do sample the ClientInfo for a ServiceWorker's own registration before
the worker is execution-ready. And prior to this patch, we only would
populate the URL during execution-ready because for most globals, we
can't possibly know the URL when the ClientSource is created. However,
for ServiceWorkers we can. Because we also want to know what the id of
the ServiceWorker client would be, we also change the creation of the
ServiceWorker ClientSource so that it uses a ClientInfo created by the
authoritative ServiceWorkerPrivate in its Initialize method.
A minor retained hack is that because the worker scriptloader propagates
its CSP structure onto its ClientInfo (but not its ClientSource, which
feels weird, but makes sense) and that does get sent via register(), we
do also need to normalize the ClientInfo in the parent when we do
equality checking to have it ignore the CSP.
Differential Revision: https://phabricator.services.mozilla.com/D180915
Currently, when a page enters BFCache, it updates the parent process
for the active BC; however, the page that is about to show will do the
same. These two operations are triggered in different processes with
different active id, they are racy and problematic.
This patch fixes the above issue by not updating the parent process
when a page enters BFCache.
This only applies to BFCacheInParent is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D215818
When using autocorrect, we should use `insertReplacementText` according
to https://github.com/w3c/input-events/issues/152. So I would like to
add eContentCommandReplaceText command for this.
Also, this command has an option that is source string text. When
processing text subsitution, parent process doesn't know whether
target replaced text is modified. So I add this option for check.
Differential Revision: https://phabricator.services.mozilla.com/D213511
Updated Content Security Policy reporting to align with current W3C reporting standards. Reporting now supports
the usage of the report-to directive, which utilizes a client's response header field to determine where a report
should be sent upon a content security policy violation occurring. Unlike the previous report-uri directive, which
parsed endpoint URIs directly from the response header, report-to utilizes endpoint groups to store the URIs
that will receive the report. This patch handles the reception of a CSP violation, creation of a report from said
violation, and report delivery, while the parsing of the endpoint URIs are handled by D193461. While the deprecated
report-uri directive remains supported, it is now only used for reporting if a client does not specify a report-
to header.
Differential Revision: https://phabricator.services.mozilla.com/D197480
Given meta/ctrl key should use browser.tabs.loadInBackground pref instead of
browser.tabs.loadDivertedInBackground pref, the existing
nsIBrowserDOMWindow.OPEN_NEWTAB behavior doesn't match the requirement.
Add dedicate flag for "open in foreground tab" to make it controllable from
nsWindowWatcher::IsWindowOpenLocationModified.
Differential Revision: https://phabricator.services.mozilla.com/D201929
GetCurrentSession now needs to know the widget to return the drag
session in content processes. It now uses an explicitly provided
window or the entry global JS context (that must be a window).
This also adds GetDragSession to DOMWindowUtils, and fixes some small
bugs in EventUtils.
Differential Revision: https://phabricator.services.mozilla.com/D211064
This shouldn't change behaviour, as the default JS MinTabSelector's behaviour
should roughly match the C++ one. The selector will be updated in a later
patch.
A new pref has been added to disable content process re-use which to replace
the test-only use-case for replacing the process selector.
Differential Revision: https://phabricator.services.mozilla.com/D213336
This shouldn't change behaviour, as the default JS MinTabSelector's behaviour
should roughly match the C++ one. The selector will be updated in a later
patch.
A new pref has been added to disable content process re-use which to replace
the test-only use-case for replacing the process selector.
Differential Revision: https://phabricator.services.mozilla.com/D213336
This shouldn't change behaviour, as the default JS MinTabSelector's behaviour
should roughly match the C++ one. The selector will be updated in a later
patch.
A new pref has been added to disable content process re-use which to replace
the test-only use-case for replacing the process selector.
Differential Revision: https://phabricator.services.mozilla.com/D213336
The builtin legacy IME of Windows to type a Unicode with typing a code point
causes consumed `eKeyDown` events while typing the code point, i.e., without
`eKeyPress` (FYI: The consumed state is not exposed to the web, it's used only
in chrome UI for the compatibility with Chrome). Then, `BrowserChild` store
whether the last `eKeyDown` was consumed or not to prevent the following
`eKeyPress`. Finally, a `eKeyPress` event is fired to input the Unicode
character after `eKeyUp` for `Alt`. The stored value is set to new value only
when another `eKeyDown` event is sent from the parent process. Therefore,
the last digit inputting `eKeyDown` causes `BrowserChild` thinking the last
`eKeyDown` is consumed so that the last `eKeyPress` is not dispatched.
This patch makes `BrowserChild` to store the `code` value of the last consumed
`eKeyDown` and check the `code` value to consider whether coming `eKeyPress`
should be or not be dispatched to `PresShell` and the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D207957
The builtin legacy IME of Windows to type a Unicode with typing a code point
causes consumed `eKeyDown` events while typing the code point, i.e., without
`eKeyPress` (FYI: The consumed state is not exposed to the web, it's used only
in chrome UI for the compatibility with Chrome). Then, `BrowserChild` store
whether the last `eKeyDown` was consumed or not to prevent the following
`eKeyPress`. Finally, a `eKeyPress` event is fired to input the Unicode
character after `eKeyUp` for `Alt`. The stored value is set to new value only
when another `eKeyDown` event is sent from the parent process. Therefore,
the last digit inputting `eKeyDown` causes `BrowserChild` thinking the last
`eKeyDown` is consumed so that the last `eKeyPress` is not dispatched.
This patch makes `BrowserChild` to store the `code` value of the last consumed
`eKeyDown` and check the `code` value to consider whether coming `eKeyPress`
should be or not be dispatched to `PresShell` and the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D207957
PresShell doesn't do anything different if it gets called with
FlushType::Display vs FlushType::Layout. It should be fine to just pass
FlushType::Layout where appropriate and remove the redundant check.
Differential Revision: https://phabricator.services.mozilla.com/D210274
This unfortunately adds some ASCII-to-UTF16 conversion because:
1. Enums use nsLiteralCString internally
2. nsAlertsService expects nsString. (macOS and Windows expects UTF16 while libnotify expects UTF8)
3. ServiceWorker events currently expect nsString. Fixing this requires touching quite some files and I filed bug 1894240 for that.
Differential Revision: https://phabricator.services.mozilla.com/D208920
Previously the `boolean` type was also declared using a `bool` typedef in
xpidl, meaning that both were used in various places. This patch standardizes
on the built-in `boolean` type, removing the typedef.
Differential Revision: https://phabricator.services.mozilla.com/D206382
Sorry for the massive patch but I found it hard to split without
introducing a bunch of copies around...
This mostly makes necko and DOM agree on which strings to use, which
should result on less copies and conversions.
Differential Revision: https://phabricator.services.mozilla.com/D205601
Given meta/ctrl key should use browser.tabs.loadInBackground pref instead of
browser.tabs.loadDivertedInBackground pref, the existing
nsIBrowserDOMWindow.OPEN_NEWTAB behavior doesn't match the requirement.
Add dedicate flag for "open in foreground tab" to make it controllable from
nsWindowWatcher::IsWindowOpenLocationModified.
Differential Revision: https://phabricator.services.mozilla.com/D201929
