Based on the usage of this in GeckoView, it wants the visual scroll
offset. Now that we populate the visual scroll offset into the
layer tree FrameMetrics as well, this works correctly, but make it
explicit by using GetVisualScrollOffset().
There is still a known correctness issue in the Layers codepath
which this patch documents.
Differential Revision: https://phabricator.services.mozilla.com/D87163
Likewise for RepaintRequest, and direct usages of mScrollOffset
inside FrameMetrics.
The general idea is:
* APZ's copy of the FrameMetrics stores the visual scroll offset,
so calls to GetScrollOffset() on it are replaced with
GetVisualScrollOffset()
* The layer tree's copy of the frame metrics (and copies derived
from that like mLastContentPaintMetrics) currently stores the
layout scroll offset, so calls to GetScrollOffset() on those
are replaced with GetLayoutScrollOffset().
The latter changes are particularly important, as they enable us
to modify the layer tree's copy to store (a main thread snapshot
of) the visual offset in mScrollOffset in a future patch.
This patch intends no functional changes. In the cases where we
change GetScrollOffset() to GetLayoutScrollOffset(), mScrollOffset
and mLayoutViewport.TopLeft() should already be storing the same
thing.
The patch identifies a few usages as suspicious but leaves them
functionally unchanged for now.
A few problematic usages of GetScrollOffset() remain, which will
require other fixes to remove.
Differential Revision: https://phabricator.services.mozilla.com/D87159
In a later patch, the main thread will start populating mScrollOffset
with its snapshot of the visual scroll offset, so to preserve the
meaning of the assertion, we'd have to call GetLayoutScrollOffset(),
making the assertion tautological.
Differential Revision: https://phabricator.services.mozilla.com/D87157
This reduces the need for conditional logic, and clarifies the model that
AsyncPanZoomController::mFrameMetrics stores the up-to-date async-scrolled
versions of the visual and layout viewport offsets, while
mLastContentPaintMetrics stores the versions as of the last paint.
Differential Revision: https://phabricator.services.mozilla.com/D87154
When adding importable logins, also add new single row autocomplete entry with fluent text and ignore it for telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D84464
Ideally this would be reworked to separate out the barrier from HashableValue
but that ended up being more work than expected. This is a small fix to clear
the value and avoid the barrier in this situation.
Differential Revision: https://phabricator.services.mozilla.com/D87293
wasm::ToCString is losing relevance as we have more constructed types. This
commit removes ToCString and replaces all uses with wasm::ToString.
Differential Revision: https://phabricator.services.mozilla.com/D85071
ref.null takes a heaptype immediate. This is backwards compatible for
reference-types, but is a breaking change for the GC proposal. This commit
implements decoding for this refinement.
Differential Revision: https://phabricator.services.mozilla.com/D85069
TypeCode::OptRef is currently used to represent any reference-typed value
for UnpackTypeCodeTypeAbstracted and IsReferenceType. I think it's actually
clearer to have this behind a named constant.
Differential Revision: https://phabricator.services.mozilla.com/D85066
wasm::Table uses wasm::TableKind to determine the element type of the table,
which makes it difficult to extend tables to support more reference types. This
commit drops TableKind in favor of directly storing the element RefType, along
with a flag for whether this table is forAsmJS, which influences the funcref
ABI. RefType is extended to return the existing TableRepr enum, which indicates
the memory representation to use for the table.
wasm::ElemSegment uses wasm::ValType, which is a superset of the allowed
types of an elem segment. This commit switches it to use the proper
RefType class, and tweaks decoding.
Differential Revision: https://phabricator.services.mozilla.com/D85064
This commit renames the TypeCode/ValType/RefType occurrences of 'any' to 'extern'
to match what they actually represent. All public API facing occurrences have
already been switched to 'externref' so this should only be aligning the
internal names with their extern usage.
Comments that only apply to 'externref' code paths are renamed as well.
Differential Revision: https://phabricator.services.mozilla.com/D85063
This commit finishes the split of wasm/gc and wasm/ref-types tests by splitting
the disabled-ref.js test into a GC test and a ref-type test.
Differential Revision: https://phabricator.services.mozilla.com/D85061
Follow-up to the previous commit that moved these tests over to wasm/ref-types,
this commit renames the tests from 'anyref' to 'externref'.
Differential Revision: https://phabricator.services.mozilla.com/D85060
The tests in wasm/gc are a mix of reftypes/gc tests. This commit adds a
ref-types folder and moves relevant tests over.
Differential Revision: https://phabricator.services.mozilla.com/D85059
The function-references spec refined ref.null to take a heaptype, which has a
slightly different text format for non-nullable references. This commit updates
tests to the new syntax.
Differential Revision: https://phabricator.services.mozilla.com/D85056
Wat now implements the module-linking proposal which includes one-level imports.
This commit removes tests of the text format which asserted these were not-valid.
Differential Revision: https://phabricator.services.mozilla.com/D85055
When we removed subtyping, we kept the anyref text syntax as an alias of
externref. This commit completes the migration over to externref. A future
commit will switch uses of externref which should be anyref back.
Differential Revision: https://phabricator.services.mozilla.com/D85053
The goal of this patch is to reduce memory usage. On at least OSX, std::Queue
can use 4kb of memory even with nothing in it. This can be around 52kb of
memory per content process.
The segment size of 64 is fairly arbitrary, but these queues didn't have
more than a few hundred items in them, so it seemed like a reasonable
trade off between space for mostly-empty queues and segment overhead.
Differential Revision: https://phabricator.services.mozilla.com/D87325
These callers should likely also function with <object> and <embed> loads, so
switching them to GetLoadingBrowsingContext() should be correct.
Differential Revision: https://phabricator.services.mozilla.com/D86583
With these changes, there are still a number of test failures when remote
object/embed is enabled, due to svg sizing and resource timing tests. In order
to land these changes before those features are fixed, it will be placed behind
a pref.
Differential Revision: https://phabricator.services.mozilla.com/D86582
By passing a weak reference back to the DocumentChannelParent into
DocumentLoadListener for object loads, we are able to handle process switching
loads by asking the content process to create a BrowsingContext, and delaying
the real process switch until it becomes available.
The load then completes as it would before, acting as a normal process-switching
subframe load.
Differential Revision: https://phabricator.services.mozilla.com/D86580
Botond Ballo
Adam Vandolder
Ed Lee
Dragana Damjanovic
Jon Coppeard
Olli Pettay
Eugen Sawin
Ryan Hunt
Andrew McCreight
Csoregi Natalia
Mark Hammond
Akihiko Odaki
Nika Layzell
Dão Gottwald
Punam Dahiya
Ricky Stewart
Nicolas Silva