This should fix some of the issues discovered by QA during their review of the
fission experiment's preference behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D92780
In order to only call `EnableControl()` twice, once in in `Open()` and another one in `Close()`, so reduce other necessary call of `EnableControl()`.
Differential Revision: https://phabricator.services.mozilla.com/D92118
When close the event source, it should be responsible to clear up and reset the virtual control interface, rather than doing so by `Media Control Server` via setting some empty results.
Differential Revision: https://phabricator.services.mozilla.com/D92116
The old way to open/close the event source, which is triggered by controller amount change event, is less intuitive, and we do the extra clean up when close the event source by assigning some parameters [1] that causes an issue on Windows where the control interface can't be clear up completely.
Each platform has its own way to clean the interface. For example, on Windows, we can simply call `ISystemMediaTransportControlsDisplayUpdater::ClearAll()`. So calling those functions actually helps nothing. The best way to do that is to ask the event source to do the clean up, rathering than setting those unnecessary parameters.
Therefore, we make it happen closer to when we determine or clear main controller and ask the event source to take a responsible to clean up when it closes.
[1] https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/media/mediacontrol/MediaControlService.cpp#410-413
Differential Revision: https://phabricator.services.mozilla.com/D92115
As we've chosen another way for GeckoView implementation, so `SetControlledTabBrowsingContextId` is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D92114
Previously we used a single texture array for a given tile size,
and resized the texture array as more tiles were needed.
However, this results in expensive driver stalls and GPU copy times
when resizing the array.
Instead, use a fixed slice count for each texture array, and support
multiple textures with the same tile size.
This may result in slightly more draw calls during compositing of
picture cache tiles due to batch breaks, but will remain a small
number due to the limited number of picture cache tiles that are
allocated at any one time.
Differential Revision: https://phabricator.services.mozilla.com/D92715
Instead of waiting until instantiation, deduplicate the bytecode as soon as
we create the stencil. This lets the stencil become immutable sooner.
Differential Revision: https://phabricator.services.mozilla.com/D92827
Where an adjustment (to reflect a delta between the APZ and layout
scroll offsets) is necessary, the inputs needed to compute the
adjustment are stored with the margins, and the adjustment is
applied at query time.
A couple of notes on this patch:
* Storing DisplayPortMargins::mLayoutOffset is probably unnecessary,
we should be able to just query the scroll frame's layout offset
when applying the margins.
* Some callers of DisplayPortMargins::WithNoAdjustment() may be
incorrect, in that they pass in margins that are relative to the
visual viewport but do not make a corresponding adjustment.
This is a pre-existing issue that this patch just makes clearer.
As this is a regression-prone area, this patch is careful to avoid
making any functional changes, leaving the above issues to be
addressed in future bugs.
Differential Revision: https://phabricator.services.mozilla.com/D92506
It's used as the offset of the visible rect, which is intended to be
relative to the layout viewport.
This is mostly hidden by the fact that we almost always
overwrite this value with the displayport rect offset.
Differential Revision: https://phabricator.services.mozilla.com/D90784
This allows mesa to continue using the existing vsync implementation
and nvidia to use the new EGL xvisual logic.
It is an intermediate solution until the issues are fixed. However,
assuming it will take a while to do so, it's probably worth it.
Differential Revision: https://phabricator.services.mozilla.com/D92466
The comment should be self-descriptive. We keep cloning the doc sync and
the UI will preview that doc, so it works out nicely and we do less
work.
Differential Revision: https://phabricator.services.mozilla.com/D92806
When requesting a highlighter instance, the inspector front returns one from its cache if present, otherwise it sends a request to the server create a new one.
But if multiple requests come in very quickly before the server responds to the original request, the cache is still empty so the front fires a few more requests. How many? It's arbitrary. As many as fit before the original request's promise resolves and the cache is set. This is the root cause for the issue of seeing duplicate highlighters.
The issue is more pronounced when there is congestion: many microtasks in the queue, for example when loading a heavy tool like the Inspector on a complex page.
To solve this, we store the unsettled promise to create a highlighter and explicitly wait for it to resolve while ignoring subsequent requests.
Differential Revision: https://phabricator.services.mozilla.com/D92802
Depends on D92499
Tweak an existing mock in the main process about:debugging test to check that we are not creating any target.
Differential Revision: https://phabricator.services.mozilla.com/D92553
This patch fixes a failure to compile on OpenBSD, and also includes the new
(and not yet used by Gecko) WebDriver implementation, and its associated
error-code upgrades.
This has a lot of new packages added into the cargo-checksum, but they were
already used by Gecko, and thus don't change the gecko-wide Cargo.{lock,toml}
files.
Differential Revision: https://phabricator.services.mozilla.com/D92784
The default styling for a ::backdrop pseudo element results in it being fully opaque and occluding all the rest of the page.
This allows us to detect that case early, and skip doing any work for the rest of the page.
Differential Revision: https://phabricator.services.mozilla.com/D91669
This patch does the following things:
(1) It removes the legacy page-range-handling function
"DetermineWhetherToPrintPage()", and it now will always print every
PrintedSheetFrame.
(2) It activates PrintedSheetFrame's page-range handling function so that it
can take over responsibility for skipping pages during print operations.
(3) It adjusts the nsPrintJob code that kicks off individual asynchronous
"print the next page" operations (which is now really "print the next
PrintedSheetFrame). This nsPrintJob code used to have page-range-related
handling interwoven into it, and that handling isn't necessary anymore now that
we're handling page-skipping up front at layout time.
(4) It replaces the mPageNum member-var (which tracks which page we're about to
print or are currently printing) with mCurrentSheetIdx, which is now a 0-based
index into the list of PrintedSheetFrame instances.
(5) It removes nsPrintData:mNumPagesPrinted, which was only used for
progress-bar-completion updates & which basically tracked the same information
that I'm tracking in the new mCurrentSheetIdx variable.
There's some additional cleanup that we should do after this lands (e.g. some
s/page/sheet/ renamings) but I'm holding off on that for now, to keep this
patch relatively targeted.
Differential Revision: https://phabricator.services.mozilla.com/D92660
This patch does the following:
* It adds better documentation for the meanings of the page range member-vars
in nsSharedPageData.
* It copies some logic (with minor tweaks) from the legacy codepath that
handles page-range support (nsPageSequenceFrame::DetermineWhetherToPrintPage())
into to the new codepath for page-range support (PrintedSheetFrame.cpp's helper
function "TagIfSkippedByCustomRange()").
At this point in the patch stack, the legacy codepath is unchanged & still
handles all print operations; and the new PrintedSheetFrame.cpp codepath only
handles page-range-skipping for the print-preview visualization in the
Tab-Modal print dialog. So, this patch effectively gives that print-preview
visualization the platform-support that it would need for complex page ranges
(though that's not available in the UI at this point, so you can't really test
that).
Spoiler alert: the next patch in this series will remove the legacy codepath
entirely, and at *that* point, the platform-native print dialog's
complex-page-range feature will be backed by the PrintedSheetFrame.cpp code
that's added here.
Differential Revision: https://phabricator.services.mozilla.com/D92696