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
- Using MonitorAutoLock/Monitor::Wait with the timeout argument instead of the eternal Wait() in CrashIfHangingRunnable::DispatchAndWait
- Augment the runnable to use an boolean to track whether or not it has effectively "resolved" with an answer so that we only write to mMsg exactly once. While the call to Wait(timeout) indicates what happened with its CVStatus return, it's necessary to make sure that WorkerRun/Cancel check this value before potentially mutating mMsg in the event they actually do run after the timed wait has given up.
- Add crash information, if the worker is a Chrome worker and in case add the executed script URL
Differential Revision: https://phabricator.services.mozilla.com/D92204
