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
In particular:
* Always handle meta viewport in RDM. This fixes bug 1625999 too by
making touch simulation enabled and disabled consistent.
* Restore the resolution to 1 when toggling RDM. This is just simpler,
and we're not keeping around the visual viewport offsets anyways
so...
* Deal with the change more easily, at the same point we switch
scrollbars etc.
Differential Revision: https://phabricator.services.mozilla.com/D206266
In bug 1883435 comment 2 chutten mentions that including
nsGlobalWindowInner.h from GleanMetrics.h causes a stylo build failure.
This is because nsGlobalWindowInner.h itself brings a bunch of DOM
bindings template soup that bindgen isn't great at dealing with.
That can be fixed in various ways. However, there is a simpler fix,
which is not including GleanMetrics at all.
It's trivial to do, and given it's a massive autogenerated file, and
Document.h is a very common header, it's worth doing this if only for
build times.
Fix a bunch of unused includes while at it.
Differential Revision: https://phabricator.services.mozilla.com/D203625
The CSS Box Sizing specification indicates that last remembered sizes
are recorded "at the time that ResizeObserver events are determined and
delivered" [1].
In bug 1807253, we changed the implementation of when proximity to the
viewport of `content-visibility: auto` nodes are determined and of when
resize observations are broadcast, in order to align with the latest
version of the HTML specification [2]. We continue to use an internal
`Document::mLastRememberedSizeObserver` to update last remembered sizes
but it has been causing issues (e.g. bug 1867090 and bug 1880928) and
could be replaced by a direct update before broadcasting resize
observations.
This is what the current patch is doing. The elements currently observed
by `Document::mLastRememberedSizeObserver` are now stored on a
`Document::mElementsWithLastRememberedSize` hashset and a new function
`Document::UpdateLastRememberedSizes` is called before broadcasting
resize observations, and peforms the work of `LastRememberedSizeCallback`
and of `CalculateBoxSize` (with `aBox=Content_box`).
The only behavior change is in the `while(true)` loop from
`DetermineProximityToViewportAndNotifyResizeObservers`: at each step
we update the last remember sizes for elements of arbitrary depth, and
don't use these depths for calculating `shallowestTargetDepth`. This is
fine, since our `LastRememberedSizeCallback` only records current box
sizes without causing significant side effects (e.g. execution of
JavaScript code) that may require a relayout.
[1] https://drafts.csswg.org/css-sizing-4/#last-remembered
[2] https://html.spec.whatwg.org/#update-the-rendering
Differential Revision: https://phabricator.services.mozilla.com/D202571
This patch doesn't change behavior.
As noted in the code-comment: ideally we should fully-modernize to nsTHashMap
or similar, but that's a larger project and will require a bit of care to be
sure we're preserving the semantics that this struct imposes on itself right
now (e.g. subdocuments clearing their parent-document pointer, as part of
removal from the map). For now, I'm just taking the incremental/trivial win of
using UniquePtr to remove explicit `new`/`delete` statements.
Differential Revision: https://phabricator.services.mozilla.com/D202904
This patch adds fetchpriority support for `<link rel=preload as=image>`
and equivalent HTTP Link header. The fetchpriority value is passed from
where the link is parsed down to `NewImageChannel` where the priority
is initially set. Currently, the default equals PRIORITY_LOW, but is
decreased a bit if LOAD_BACKGROUND flag is set (this is always the case
for link preload images, see `imgLoader::LoadImage`). Later, the
priority can be increased again depending on the category (see
`imgRequest::BoostPriority`).
In order to minimize the changes, the new calculation is to keep the
initial setting to PRIORITY_LOW, adjust it using a new
`network.fetchpriority.adjustments.*` preference depending on the
fetchpriority attributes, and then preserve further adjustments for
LOAD_BACKGROUND and `BoostPriority`.
For the default value `fetchpriority=auto`, there is no adjustment
i.e. we continue to start with PRIORITY_LOW. `fetchpriority=low/high`
are respectively mapped to PRIORITY_LOW/PRIORITY_HIGH which is simple
and consistent with the "Image" cases from Google's web.dev article
https://web.dev/articles/fetch-priority. These values could of course
be revised in the future after more experiments.
This change is covered by the following tests below. The expectations
is modified to match what is described above (i.e. map to PRIORITY_LOW
or PRIORITY_HIGH with adjustment due to LOAD_BACKGROUND):
- `link-initial-preload-image.h2.html`
- `link-dynamic-preload-image.h2.html`
- `kPipeHeaderPreloadImageLinks`
Based on a patch by Mirko Brodesser (mbrodesser@igalia.com)
Differential Revision: https://phabricator.services.mozilla.com/D197493
This patch adds fetchpriority support for `<link rel=preload as=image>`
and equivalent HTTP Link header. The fetchpriority value is passed from
where the link is parsed down to `NewImageChannel` where the priority
is initially set. Currently, the default equals PRIORITY_LOW, but is
decreased a bit if LOAD_BACKGROUND flag is set (this is always the case
for link preload images, see `imgLoader::LoadImage`). Later, the
priority can be increased again depending on the category (see
`imgRequest::BoostPriority`).
In order to minimize the changes, the new calculation is to keep the
initial setting to PRIORITY_LOW, adjust it using a new
`network.fetchpriority.adjustments.*` preference depending on the
fetchpriority attributes, and then preserve further adjustments for
LOAD_BACKGROUND and `BoostPriority`.
For the default value `fetchpriority=auto`, there is no adjustment
i.e. we continue to start with PRIORITY_LOW. `fetchpriority=low/high`
are respectively mapped to PRIORITY_LOW/PRIORITY_HIGH which is simple
and consistent with the "Image" cases from Google's web.dev article
https://web.dev/articles/fetch-priority. These values could of course
be revised in the future after more experiments.
This change is covered by the following tests below. The expectations
is modified to match what is described above (i.e. map to PRIORITY_LOW
or PRIORITY_HIGH with adjustment due to LOAD_BACKGROUND):
- `link-initial-preload-image.h2.html`
- `link-dynamic-preload-image.h2.html`
- `kPipeHeaderPreloadImageLinks`
Based on a patch by Mirko Brodesser (mbrodesser@igalia.com)
Differential Revision: https://phabricator.services.mozilla.com/D197493
The event is emitted when a property is registered via `CSS.registerProperty`.
This will be used by DevTools so we can update the Rules view when a property
is registered.
Differential Revision: https://phabricator.services.mozilla.com/D196204
It seems the discussion in the bug goes in this direction, and I think
it's the right call as described there.
Depends on D198630
Differential Revision: https://phabricator.services.mozilla.com/D198669
`beforeinput` event shouldn't be fired if it's caused by JS. However, we
dispatch it when the call is by chrome script or an addon because there is
no user input emulation API for WebExtension and builtin editors make the
change undoable only when JS changes the editor value with
`Document.execCommand`. Therefore, addons may want to use
`Document.execCommand` for making the change undoable.
On the other hand, nested calls of `Document.execCommand` makes the error
handlings in editor classes too complicated. Therefore, we don't allow that.
However, this causes that if web apps intercept `beforeinput` events and
prevents the default and calls `document.execCommand`, the first call of
web apps may be first nested call if the `beforeinput` event is caused by
a call of `Document.execCommand` in addon.
Therefore, this patch makes `Document` stores whether `ExecCommand` is called
by content or chrome/addon. And if the call is improperly nested, keep stopping
handling the command, but allows if and only if the first call is by
chrome/addon.
Differential Revision: https://phabricator.services.mozilla.com/D198357
In order to use the modifiers in nsGlobalWindowOuter::OpenInternal, add accessor
methods to BrowsingContext, Document, and WindowContext.
Those accessors behave in the same way as ConsumeTransientUserGestureActivation
and RevisePopupAbuseLevel, except for checking the PopupBlocker state.
Differential Revision: https://phabricator.services.mozilla.com/D197862
