Only "custom" invoke actions (those with a dash) or well-defined built-in
actions can be defined. Auto action is now implicit from empty/null atom.
Differential Revision: https://phabricator.services.mozilla.com/D206182
Inline Create() and Realloc() so that we don't get negative leaks, since
were that code end up in mozglue, it wouldn't have access to the logging
machinery.
Differential Revision: https://phabricator.services.mozilla.com/D209663
Ths patch introduces a new class called `CrossShadowBoundaryRange` to
make cross shadow boundary range related stuff can be isolated into a
single class.
It also tweaks a few functions along the call stack, the goal here
is to make sure nsContentUtils::IsPointInSelection can detect points
in ShadowDOM selection.
There's an additional change to `SelectionUtils.sys.mjs` to make sure
the correct context menu items are displayed when the current selection
crosses the boundary.
Differential Revision: https://phabricator.services.mozilla.com/D204080
After bug 306344 this is the last remaining incompatibility with
<marquee>. I think we should be able to drop it. Use counters for
"finish" are relatively high (>0.1%), but I'm pretty sure that's because
that event name is shared with web animations. "bounce" is a more
realistic measure, and that's 0.003%, which is more expected.
Differential Revision: https://phabricator.services.mozilla.com/D206387
This new cache implementation keeps the last N node/index combos in a stack-allocated array, which will be queried before calling nsINode::ComputeIndexOf().
Differential Revision: https://phabricator.services.mozilla.com/D203900
This new cache implementation keeps the last N node/index combos in a stack-allocated array, which will be queried before calling nsINode::ComputeIndexOf().
Differential Revision: https://phabricator.services.mozilla.com/D203900
This new cache implementation keeps the last N node/index combos in a stack-allocated array, which will be queried before calling nsINode::ComputeIndexOf().
Differential Revision: https://phabricator.services.mozilla.com/D203900
This new cache implementation keeps the last N node/index combos in a stack-allocated array, which will be queried before calling nsINode::ComputeIndexOf().
Differential Revision: https://phabricator.services.mozilla.com/D203900
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
nsJSUtils::GetCallingLocation is used mostly for console message and logging,
except for the following:
* profiler label in TimeoutHandler
* CC log for TimeoutHandler
* events in nsIConsoleAPIStorage
* JSON used by mozilla::dom::SendReports
Differential Revision: https://phabricator.services.mozilla.com/D193370
