These are most of the changes needed to get a build with AV1.
The crypto/openssl changes are later altered in the stack adding an NSPR based implementation of the functionality that was missing.
Differential Revision: https://phabricator.services.mozilla.com/D228540
The previous patch makes the PiP window have rounded corners and shadows
on Windows (like on macOS).
That uncovers some cases where PiP was using inner rather than outer
sizes incorrectly, mostly in test code. This wasn't a problem before my
patch because innerSize used to be the same as outerSize before my
patch.
I _could_ restore the previous behavior (by using hidechrome="true" or
so), but I think this is nicer, and the code works with outer sizes
regardless (i.e., if we want to restore the old behavior we don't need
to touch any of this code, just add hidechrome, so that outer and inner
sizes match).
Note that all the code in PictureInPicture.sys.mjs already deals with
outer sizes (correctly so).
Differential Revision: https://phabricator.services.mozilla.com/D229523
Previously, some tests were failing because the interval function was not immediately
cleaned up when didDestroy() was called, which kept some references around and prevented
objects from being garbage collected.
I solved this by recognising that there are two ways that a promiseObserve can exit without
success: when the timeout expires, and when the CookieBannerChild is destroyed. These need
to be handled differently, so I gave each case a different AbortController.
Differential Revision: https://phabricator.services.mozilla.com/D227095
When the `cleanup()` function inside `#promiseObserve()` gets called with the result of the banner search,
it cancels the `observerCleanUpTimer`, which can then no longer clean up the *Button* observer.
I fixed this, and also other potential async timing issues, by stopping the cleanup function from cancelling
the timeout, and having the timeout set a persistent "givenUp" flag instead of trying to directly cancel the
promiseObserver.
Differential Revision: https://phabricator.services.mozilla.com/D221582
There are two implementations of (set|clear)(Timeout|Interval) at play here: a Javascript implementation
from toolkit/modules/Timer.sys.mjs used by browser components, and a C++ implementation from
dom/base/TimeoutManager.cpp that is exposed to web pages.
CookieBannerChild.sys.mjs was creating timers with the C++ implementation, taking those IDs, and then
trying to clear them in the Javascript implementation. The two implementations have individual ID namespaces
so this resulted in unrelated timeouts being inadvertantly cancelled and the intended one continuing on.
Differential Revision: https://phabricator.services.mozilla.com/D221261
Some misc changes:
- ValTypeVector& is moved into OpIter so it doesn't need to be
passed to readLocalGet, etc. This is to help prepare for printing
init expressions which don't have locals.
- Some OpKind variants did not match the name of the readXYZ method
on OpIter.
- Some OpIter methods need to return slightly different types.
The instruction opcode names have not been thoroughly audited, some
of them may be wrong.
Eventually I'd like to evolve this into a spec compliant binary to
text printer for use in devtools.
Differential Revision: https://phabricator.services.mozilla.com/D228612
The `BottomToolbarContainerIntegration` through it's internal `ToolbarBehaviorController`
controls whether the toolbar should be dynamic or not depending on the state of the
current browser tab.
Since on the home screen there in no active browser tab and the toolbar from the home screen is
always fixed in place and not dynamic there is no need for `BottomToolbarContainerIntegration`.
Differential Revision: https://phabricator.services.mozilla.com/D228183
This was initially meant to only control the scrolling behavior of the toolbar.
The later added functionality to also control the toolbar functionality depending
on if search is active or not is suboptimal with the toolbar visibility updates being
too slow:
- when search is active this should hide the toolbar
This was too slow to happen leading to two toolbar shown on screen, issue for which
another patch was needed as part of bug 1895573.
- when search is closed this should show the toolbar
This is too slow and leads to having no toolbar on the screen immediately after search
is closed.
We get the visibility update after a few tens of milliseconds so on the homescreen the
toolbar will be shown but a flicker can still be seen and the visibility change happens
too late - in the case of a search started from browser we'd try showing the homescreen
toolbar after the user gets back to the browser.
Differential Revision: https://phabricator.services.mozilla.com/D228182
Since when entering search we hide the navbar but keep the addressbar visible when
exiting search we need to show back the navbar - if applicable.
Using the result listener framework is much faster than relying on store updates to
know if search is visible or not (instant vs ~60ms on a Pixel 6) allows to transition
from the search toolbar to the home screen toolbar in just one visual frame.
Differential Revision: https://phabricator.services.mozilla.com/D228181
