The code in CalculateAndSetDisplayPortMargins computes metrics for the content,
which may be the RCD and therefore have separate visual and layout scroll offsets.
The code then uses CalculatePendingDisplayPort to compute displayport margins,
but that function computes the margins based on the visual scroll offset. The
code then uses that as the final margins, when in fact those margins might
need adjusting so that they can be applied to the base rect (which is based
on the layout scroll offset).
This function is invoked by MobileViewportManager after load complete, at
which point the displayport may already be set and the layout and visual offsets
may have diverged. This can happen if, for example, the user manipulates the
visual viewport early during page load, or if a visual viewport is restored
after navigating backwards. In these scenarios the existing "with adjustment"
displayport margins are clobbered by the new, incorrect "with no adjustment"
margins. This patch corrects this by specifying the necessary adjustment.
All the other call sites of this function only call it to initialize the
displayport for the first time, so they cannot run into this problem of
"clobbering" an existing margins. However, I kept this patch general enough
so that if any of those call sites were to change in the future, it wouldn't
run into the same problem.
Differential Revision: https://phabricator.services.mozilla.com/D93494
These unit tests were going through chunks very quickly in tight loops, which on some platforms could cause successive chunks to be marked "done" with the same timestamps.
Distinct timestamps are needed to uniquely identify chunks (in each process), and related assertions caught that. In real Firefox code, chunks are much bigger (around 1MB), and fill at a slower rate, so timestamps are always different as expected there.
To fix this artificial issue in our unit tests, delays are introduced before each `MarkDone()`, to ensure that they'll get a different timestamp every time.
Differential Revision: https://phabricator.services.mozilla.com/D93479
The existing gc tests relied on struct <: externref in various ways,
this commit fixes this.
Additionally a new test is added for checking we have dynamic tests
for eqref on all wasm value entry points.
Differential Revision: https://phabricator.services.mozilla.com/D93002
Give ref.eq type of [eqref, eqref] : [i32], closing a corner case where boxed
JS values could be compared for equality.
Restrict struct.narrow to operate on eqref, as that's the super type of structs.
This also allows us to drop an unboxing from externref -> typed object as that
is now done in all wasm entries.
Differential Revision: https://phabricator.services.mozilla.com/D93001
This commit adds support for the eqref value type. It shares the same
representation as externref, with the restriction that all values must
be TypedObject's. Dynamic type checks similar to funcref are added to
stubs.
As fallout from anyref removal, struct types were left as subtypes of
externref. This commit switches them to be subtypes of eqref.
As a small tweak, the ordering on cases when switching on refTypeKind()
were standardized to binary order (i.e. funcref, externref, eqref).
I think we can refactor some code to simplify the process of adding
new reftypes and would like to do that in the future.
Differential Revision: https://phabricator.services.mozilla.com/D93000
Besides the ARIA role invalidation, this fixes an issue where the mozAccessible's role is also incorrect when the aria role changes on a body tag.
Depends on D93439
Differential Revision: https://phabricator.services.mozilla.com/D93440
Most platforms have scrollbars > 16 pixels in width. This typically
reduces the number of native layers allocated on most platforms for
scrollbars. This is quite important as the fixed overhead of each
native layer is relatively high on DC and CA.
Differential Revision: https://phabricator.services.mozilla.com/D92871
This patch removes the last use of clipped_world_rect, and removes
it from the PrimitiveVisibility struct.
Instead, the already calculated tile rect is used for visibility
determination when picture caching is enabled. When picture caching
is disabled, the clipped world rect is calculated on demand but
not stored.
This patch also introduces an enum for current visibility state,
which gives better control over accessing visibility information
depending on the current pass of frame building.
Differential Revision: https://phabricator.services.mozilla.com/D92545
The CGFonts end up in a cache that we don't want. Creating the CTFonts
directly should avoid this.
Notes:
add_native_font normally takes a CGFont and we need a CTFontDescriptor
so we convert to postscript name and then postscript name to
CTFontDescriptor. This is wasteful but avoids needing to change the
external API.
To avoid copying the data in the Vec we use a CFAllocator to wrap the
Vec for use by CFData
Differential Revision: https://phabricator.services.mozilla.com/D93518
This patch removes the public API and high level logic for
disabling picture caching for debugging and pinch-zoom in
some cases.
Follow up patches will remove and simplify the internal parts
of WR that remain to handle the disabled picture caching
code path.
Differential Revision: https://phabricator.services.mozilla.com/D93446
This allows apps to modify the header filtering behavior, and introduces a safe
default (CORS safelisted).
Deprecated `loadUri` methods still maintain the old behavior so that we don't
inadvertently introduce bugs in apps.
Differential Revision: https://phabricator.services.mozilla.com/D91983
This introduces a new way of loading URIs in GeckoSession, using a builder-like
method `loader()` which deprecates the existing `loadUri`.
This change improves readability of long `loadUri` calls and allows us to add
more parameters without compromising usability.
It also fixes a bug where we were not short-circuiting the `onLoadRequest` call
in some cases.
Differential Revision: https://phabricator.services.mozilla.com/D91982
* Only use paperWidth/paperHeight values from the settings when searching for a paper size match
* Calculate unit-appropriate values for paperWidth, paperHeight and write them to settings whenever a paper size is selected
* Always write paperSizeUnit and the width/height values to settings to ensure any bad data from prefs is overwritten
Differential Revision: https://phabricator.services.mozilla.com/D91021
The goal is to stop using the listener.js framescript to support navigation in reftests using marionette.
Instead we will port the current logic to JSWindowActor.
Differential Revision: https://phabricator.services.mozilla.com/D92648
- The presShell id seems to be not very useful, so drop it.
- Be more explicit about the scrollId which is generally quite useful (I always
have a hard time remembering which number is the scrollId)
- Label the RCD node with "rcd" rather than a "1" vs "0"
Differential Revision: https://phabricator.services.mozilla.com/D93436
It would be good for us to know how many websites actually use MediaSession API to control (play/pause/stop) their media playback, an how many websites use our default handler.
Differential Revision: https://phabricator.services.mozilla.com/D93283
Each platform has different ways to allow users to use media control, adding a telemetry probe to detect that would be good for us to know the usage among different platforms.
Differential Revision: https://phabricator.services.mozilla.com/D93282
This is a pretty simple implementation of the approach discussed in the bug. When a tab-to-search result is shown, we announce it to screen readers. We keep track of which engines are announced to be sure we don't keep announcing the same engine as the user types.
This approach is maybe slightly crude, but I didn't find a working elegant approach. One approach I considered is checking for tab-to-search results in the loop in UrlbarView._updateResults. After the loop is finished, if we found a tab-to-search result, we go back and change the aria-label on the action text of the prior result to something like "Visit, or press Tab to search with { $engine }. This didn't work because we don't read action text for the heuristic result as the user types. This is presumbably to avoid disrupting the user as they type. This is what my patch does regardless, however... Since Jamie was skeptical about whether we should announce this at all, I put this behaviour behind a default-true pref, browser.urlbar.tabToSearch.accessibility.announceResults.
Differential Revision: https://phabricator.services.mozilla.com/D93451
This commit removes all tests that used the old TypedObject API.
We may be able to salvage some of these tests in the future when
the Wasm GC API is clearer, but for now remove them.
Differential Revision: https://phabricator.services.mozilla.com/D92860
When navigating to a new URL that requires a remoteness change, session store
restores the tab after the change. The restore races the `gURLBar.setURI` call
that happens due to the location change. If the restore happens after the
`setURI` call, then the search mode is "restored" even though a new page was
loaded.
The session store code surrounding the chunk that I modified in bug 1655486
checks for a remoteness change before trying to restore `userTypedValue`. If the
restore is due to a remoteness change, then it doesn't restore `userTypedValue`.
We just need to do the same for search mode.
Also, I think we should be using `TabStateCache` here, not `TabState.collect`.
`TabStateCache` is updated in `restoreTab` and is available throughout the
restore process. `TabState.collect` on the other hand is a live view of the
given tab, so if search mode happens to be active when `collect` is called, then
the returned tab state will have `searchMode` defined, which is not what we want
here. But I'm not sure why the surrounding code here uses `TabState.collect`
instead of `TabStateCache` in order to restore `userTypedValue`. It seems like
an error to me, but I might be missing something.
Due to the racey nature of this bug, writing a test isn't so easy, so this patch
doesn't have one. It will be obvious through manual testing if this regresses.
Differential Revision: https://phabricator.services.mozilla.com/D93455
