This means that double tapping on an oop iframe "works" in that we don't try (and fail) to zoom the oop iframe. But it also means it is impossible to zoom to some content inside that oop iframe. Instead the best we can do is zoom to the oop iframe itself. This is consistent with what Chrome and Safari currently do. Allowing zooming to content inside an oop iframe would be decently complicated and it doesn't seem worth it. Bug 1715179 is on file for this.
Differential Revision: https://phabricator.services.mozilla.com/D116925
We had the constant `kMaxEvents` which limits the maximum number of loading
events in `UntrustedModulesData`. Because we had a check for the number of
events in `UntrustedModulesData::AddNewLoads` where we already swapped
`UntrustedModulesProcessor::mUnprocessedModuleLoads` with a local variable,
when the array exceeds `kMaxEvents`, we discarded the remaining loading events.
The proposed fix is to check for `kMaxEvents` before swapping the unprocessed
events, so that the remaining events will be processed the next time.
This was caught by the `UntrustedModulesFixture` GTest. This test had
another test bug that it always expected modules were loaded in the main
thread except the predefined known modules. This is not correct because
the same process may have loaded a bunch of modules in the earlier GTests
such as graphics drivers in different threads. This patch includes a fix
for that bug as well.
Differential Revision: https://phabricator.services.mozilla.com/D117433
- Replace DMABufSurfaceWrapper array by FFmpegVideoFramePool and create it only when DMABuf/VA-API is used.
- Use FFmpegVideoFramePool to allocate/recycle video frames backed by DMABuf surfaces.
- Enable SW decoding to DMABuf surfaces only when VA-API is enabled to avoid potential breakage (keep recent state).
- Disable VA-API / DMABuf decoding when WebRender is not used.
- Remove DMABufSurfaceWrapper class.
Depends on D117222
Differential Revision: https://phabricator.services.mozilla.com/D117223
- Implement abstract class for video frames named VideoFrameSurface
- Implement VideoFrameSurfaceDMABuf class for video frames uploaded to DMABuf memory from SW decoding.
- Implement VideoFrameSurfaceVAAPI class for video frames decoded by VA-API.
- Implement VideoFramePool to create and recycle video frames.
Depends on D117221
Differential Revision: https://phabricator.services.mozilla.com/D117222
- Split VA-API / DMABuf video images decoding to CreateImageDMABuf() and CreateImageVAAPI(). CreateImageVAAPI() is used for VA-API only and CreateImageDMABuf() for images decoded by SW and uploaded to DMABuf.
- Implement FFmpegVideoDecoder::InitHWDecodingPrefs() where VA-API related prefereces are processed.
- Change mDisableHardwareDecoding to mEnableHardwareDecoding for better readability.
- Implement nsDMABufDevice::IsDMABufVideoEnabled() to explicitly configure dmabuf texture setup.
- Remove unused AllocateYUV420PVideoBuffer() prototype.
Differential Revision: https://phabricator.services.mozilla.com/D117220
Automatic update from web-platform-tests
cc Rename one ARIA test, and update messages.json
--
wpt-commits: 6ce585b845874728b6c7c6bdf312cc1ed12ca4a4
wpt-pr: 29396
Automatic update from web-platform-tests
Update sticky position pushed beyond scrollable range test.
The css-position spec[1] was updated to suggest that sticky positioned
elements are only shifted after layout within their containing block.
This would imply that the now unified behavior across browsers matches
the new spec expectations. This updates the test to match what the
browsers do.
[1] https://drafts.csswg.org/css-position-3/#stickypos-insets
Bug: 752022
Change-Id: Ic95d32948f9088ae4592a3de78d6ac0a58db8183
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2960015
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#892805}
--
wpt-commits: 05ab45fb425416018d4bfa23ee3a65b5d37f593b
wpt-pr: 29368
Automatic update from web-platform-tests
Safe slot reassigment
1. Use GetWithoutInvalidation() instead of Get() in DCHECKs.
We should never call Get() inside of a DCHECK(), because this can
lead to a different code path depending on whether DCHECKs are enabled.
2. Get() should not cause immediate side effects. At most, it should
queue up an invalidation for later processing.
Fixing #1 and #2 were required in order to get past a first set of
errors introduced by the new test.
3. The actual fix -- avoid infinite loop by calling a special
new SlotAssignmentWillChange(), rather than ChildrenChanged(),
where a minimal GetWithoutInvalidation() is called that does not
lead to IsShadowContentRelevantForAccessibility() => FirstChild() =>
RecalcAssignedNodes() => ChildrenChanged() ... (infinite loop).
A simpler potential fix is in CL:2965317 but requires more
research. It's also mentioned in a TODO comment.
Bug: 1219311
Change-Id: Iafaa289f241a851404ce352715d2970172a2e5f8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2961158
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#892778}
--
wpt-commits: 7b9ca7da96108c39142ebf9b6d639d9725beebf4
wpt-pr: 29388
Automatic update from web-platform-tests
[css-flex] Migrate more abspos tests from reference to check-layout
Before this patch, the entire test file is marked Fail even though each
file has ~15-20 tests in it, some of which Blink passes. If we were to
regress any of the tests we pass, we'd never know.
This patch shows that Blink disagrees with Firefox in any wrap-reverse
container and some justify-content:space-between containers.
Change-Id: I3ce1120a47f85a89ecfbea9952b15514bc1c58e4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2965267
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Commit-Queue: Christian Biesinger <cbiesinger@chromium.org>
Commit-Queue: David Grogan <dgrogan@chromium.org>
Auto-Submit: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#892738}
--
wpt-commits: 38ba3d82c68c3f79d9a24350ff1960a493c65d5c
wpt-pr: 29391
Automatic update from web-platform-tests
[wpt] Fix grid aspect-ratio tests.
There two tests were asserting that "min-width: auto" would clamp the
inline-size to the available inline-size, even though we had a
transferred inline-size.
(Firefox has the same behaviour as us if "min-width: 0").
This updates the tests to respect the transferred inline-size.
Bug: 1203090
Change-Id: I02e10d3393f74cce0979b483629d1d6cea33d10d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2961536
Auto-Submit: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Commit-Queue: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#892731}
--
wpt-commits: cf132901347a5159fa0b969819505b9a414a2128
wpt-pr: 29369
Automatic update from web-platform-tests
Remove some unnecessary switch to window commands from testdriver
--
Ensure we set a testdriver context when running in a non-test window
testdriver can be used outside the test window in two ways:
* By passing in a context parameter pointing to another window in
which the commands should be run.
* By loading testdriver in the other window and having it postMessage
commands back to the top window.
For the first case the context parameter being null means "run the
command in the test window". However we were also passing null in the
second case when the command should be run in the window where
testdriver was loaded. That meant the command was actually run in the
test window rather than the target. It just so happened this didn't
cause test failures in Chrome and Firefox because of the specific
choice of commands in the tests. But it did in Firefox with site
isolation enabled and Safari and would for a different set of tests.
The fix is to ensure that the context is always set when postMessaging
a command to the top-level window.
--
Only skip switching to the current window if we didn't already switch to a different window
--
Only try to switch to parent if we are processing a frame
--
wpt-commits: c0302954a41ac1c442beca0227a7fb2208f96dc6, b32b3e223f63dc5500de31dfc117a03ec582f38d, 27e1c32dd3ad67a06a07ebc0d1e4809e3f05eb9b, 6a943265f49d7c5de263c6d2f5de36531d10e8e8
wpt-pr: 26411
Automatic update from web-platform-tests
URLPattern: Collapse look-ahead loops into main parse loop.
This CL refactors the parser to use separate states instead of the
previously implemented look-ahead loops. This fixes a bug where the
look-ahead loops did not properly ignore characters within `{ }`
pattern groupings.
This CL also slightly improves handling for nesting `{ }` groupings
even though they are not legal pattern syntax. It seems better to
avoid getting confused on depth and let the later pattern compiler
return a more predictable error.
This CL also adds a number of additional comments and other cleanup.
Bug: 1141510
Change-Id: Id6bc1b4a16390b9e878c6757582519997332bbc8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2951204
Commit-Queue: Ben Kelly <wanderview@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#892699}
--
wpt-commits: 3b7d310344e0ea8eb032ce9ad3e588a86216cd54
wpt-pr: 29390
Convert all JS_FRIEND_API to JS_PUBLIC_API. At this point, the JS_PUBLIC_API has
no formal curation process and in practice we add a lot of new features to
JS_FRIEND_API without giving much thought to if they should be public. The
result is that all embedders need to use the friend API in some form and the
distinction has lost meaning.
Going forward, we should continue to use the js/public/experimental directory as
a place to expose new APIs, and in general should strive for high quality of the
APIs that are exposed. If a particular API is tricky or discouraged, comments
explaining that will be more helpful that a losely applied FRIEND_API marker.
Differential Revision: https://phabricator.services.mozilla.com/D117607
Currently we fail to display anything when using the Nvidia EGL
implementation. Similar issues seem to happen in GTK4.
If we're lucky this will be fixed by future Nvidia drivers as they
started to adopt DMABUF/GBM.
Differential Revision: https://phabricator.services.mozilla.com/D117434
This speeds up reflows on pages like view source that have a single
giant container. But this maybe slows down other cases? I'm not 100%
sure.
Differential Revision: https://phabricator.services.mozilla.com/D117948
We sync layout history state on doc shell removal, and we may have discarded a
context for an out-of-process frame before ContentParent receives the
synchronize message.
Differential Revision: https://phabricator.services.mozilla.com/D118003
We always support these functions, so no need to use dlsym. The csd type
technically depends on the theme I think, so caching it globally is
wrong. Instead compute it once and pass it down to the two callers that
care about it.
Differential Revision: https://phabricator.services.mozilla.com/D117722
This speeds up reflows on pages like view source that have a single
giant container. But this maybe slows down other cases? I'm not 100%
sure.
Differential Revision: https://phabricator.services.mozilla.com/D117948
