This method only asserts that mInitialized is false, then sets
mInitialized to true. All call sites check that the flag is false,
so the assertion is redundant, so this method can be inlined
and simplified.
Differential Revision: https://phabricator.services.mozilla.com/D89480
This change allows the api to talk directly to the scene builder thread. This avoids unpredictable and sometimes large latency caused by scene builder requests sitting in a busy render backend's event loop.
Differential Revision: https://phabricator.services.mozilla.com/D74055
Depends on D86162
The resource watcher already guarantees that listeners are only called once, caches resources etc.
Consequently, the client side logic currently implemented in the WalkerFront is redundant and should be removed.
Differential Revision: https://phabricator.services.mozilla.com/D86163
When session history is in the parent we can read state directly from it,
instead of waiting for the child process to send a message with the updated
state. The old mechanism (BrowserParent::RecvOnLocationChange calling
UpdateWebNavigationForLocationChange) is still needed for when session history
in the parent is turned off. We'll remove it eventually, once session history in
the parent sticks.
Differential Revision: https://phabricator.services.mozilla.com/D89418
Also ship to release if the Intel driver is 21.20.16.4550 or later.
Add Intel Gen 6 GT1 (Sandybridge) and allow it to ride to early beta.
Differential Revision: https://phabricator.services.mozilla.com/D89613
These were there to prevent crashes because when the type of the frame
changes dynamically we would mess up and fail to find the right
insertion point.
We deal with this correctly nowadays:
https://searchfox.org/mozilla-central/rev/b2716c233e9b4398fc5923cbe150e7f83c7c6c5b/layout/base/nsCSSFrameConstructor.cpp#8521-8536
And the list was never exhaustive in the first place (e.g., writing-mode
can also cause us to reframe, and so do a bunch of other properties). So
there's no real reason to be so strict anymore.
Also change ::-moz-complex-control-wrapper while at it too, because it's
not web exposed so there's no need for those declarations in the first
place.
Differential Revision: https://phabricator.services.mozilla.com/D89586
Per the comment in the patch: if we're given a bogus range, we can technically
end up with a single PrintedSheetFrame that contains no displayable
pages. Luckily, that's a situation that the frontend should detect & recover
from quickly & gracefully, so it's not really a problem. So: in that scenario,
we'll now spam a non-fatal warning; and we'll fatally assert if any sheet
*beyond* the first page has zero displayable pages. (That still shouldn't be
possible.)
Differential Revision: https://phabricator.services.mozilla.com/D89537
Given all of the MOZ_TRYs in WriteToDisk, it's entirely possible that
we occasionally exit it before writing everything out. WriteToDisk
additionally adds guards to try to ensure that we do not call it twice,
and that we do not try to read things out of the file via the memmapped
buffer after it has written to it. The latter should not generally be
a problem, since we write to a temp file and move that over at the end.
However, writing twice could be a problem as we modify our values'
mOffsets to keep track of their offsets within the resulting file.
Accordingly, this change simply moves the cleanup and guards into an
RAII helper to ensure they survive all of the early returns.
Differential Revision: https://phabricator.services.mozilla.com/D89253
We have a tls dependency in callWithABI for wasm because we call builtins via BuiltinThunk.
Last one requires that tls to be loaded. In this patch I gradually extend callWithABI interface to
pass offset to tls. This allows us to preserve tls and load it by offset in callWithABI and frees us from
the Frame::tls dependency.
Differential Revision: https://phabricator.services.mozilla.com/D88426
Bug 1661030 refactored SubDialog to support passing multiple window arguments.
Before that window.arguments was always an array with one element, even if the
caller did not pass any data.
window.arguments should be null checked before accessing it.
However, in this case the arguments were unused, so I removed the assignment.
Differential Revision: https://phabricator.services.mozilla.com/D89584
The 'allowDuplicateDialogs' option covered up a bug where we had two click event listeners for the
changeBlockListLink. This should fix the duplicate dialog.
However, there seem to be timing issues with the 'allowDuplicateDialogs' option we should look
into as follow up work.
Differential Revision: https://phabricator.services.mozilla.com/D89585
