The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
WindowFeature provides the tokenization and access to the map.
This changes the following behavior:
* "*" value is removed, given it's unused.
* Default width and default height handling is removed,
given there's no callsites
* Some chrome-priv feature handling becomes stricter:
* All substring match is removed and directly checks the item in the map
Also, fixed noopener=0 and noreferrer=0 options to be handled properly.
Differential Revision: https://phabricator.services.mozilla.com/D67725
WindowFeature provides the tokenization and access to the map.
This changes the following behavior:
* "*" value is removed, given it's unused.
* Default width and default height handling is removed,
given there's no callsites
* Some chrome-priv feature handling becomes stricter:
* All substring match is removed and directly checks the item in the map
Also, fixed noopener=0 and noreferrer=0 options to be handled properly.
Differential Revision: https://phabricator.services.mozilla.com/D67725
In particular, this correctly treats as invalid patterns like "a)(b" that only "become" valid due to the addition of the (?:) non-capturing group, that's originally used to allow the addition of ^ and $ anchors.
Differential Revision: https://phabricator.services.mozilla.com/D70143
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
This is a mistake implementation of cutout support.
When OS/device doesn't support cutout (safe-area-insets-*), widget returns 0 for safe area insets values.
So if it is 0, we shouldn't set safe-area-insets.
Also, I will add test for this by bug 1622713. Actually, no Android emulator that supports notch.
Differential Revision: https://phabricator.services.mozilla.com/D67275
Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
`InputEventOptions` should be able to take target ranges for `beforeinput`
event. However, it requires to include `StaticRange.h` from `nsContentUtils.h`
even though most `nsContentUtils.h` users don't need it. Therefore, this patch
moves it from `nsContentUtils.h` to new header file.
And makes `nsContentUtils::DispatchInputEvent()` moves the target ranges
from `InputEventOptions` to `InternalEditorInputEvent`.
Differential Revision: https://phabricator.services.mozilla.com/D64729
We would before always prefer the error name and message contained in the JSErrorReport,
and that was probably ok, because ErrorReportToMessageString in xpc did basically the same thing as
ErrorReportToString in js. However now that we have special code to try and retrieve overwritten
name and message properties we need to prefer aToStringResult.
There was one caller in ContentUtils that explicitly passed "<unknown>" for aToStringResult,
all other callers either use nullptr or js::ErrorReport::toStringResult().c_str.
Differential Revision: https://phabricator.services.mozilla.com/D64350
