This ended up being a lot more straight-forward than the menu changes.
TLDR:
* nsMenuBarFrame -> XULMenuBarElement
* nsMenuBarListener -> MenuBarListener
Rest should be rather straight-forward.
Depends on D168649
Differential Revision: https://phabricator.services.mozilla.com/D167809
Not sure if you think this is worth it, it might be in some cases where
we have pre-atomized stuff in the container.
Depends on D169142
Differential Revision: https://phabricator.services.mozilla.com/D169143
Base64 encoding is done to top-level principal and the sub-principals
of expanded principals. Getting rid of the Base64 encoding entirely
also lets us use jsoncpp consider expanded principals to be entirely
serialized as JSON.
Differential Revision: https://phabricator.services.mozilla.com/D166783
This patch attempts to fix intermittent failures by:
1. using `ensureMaximizedWindow()` where appropriate. While nothing
seemed wrong per se with the previous approach, resizing to the
original height was done to restore the previous window dimensions.
Since the window is maximized before, it makes sense to reuse this
helper function, especially given that it is a bit more robust than
just awaiting an event.
2. not awaiting the `resize` event, which does not seem to be fired all
the time when `resizeBy()` is used. It was mostly fine, except when
it wasn't... Since we have a `.waitForCondition()` call right after,
we can probably skip the await of this event.
Differential Revision: https://phabricator.services.mozilla.com/D169088
I've been tried to bisect if this intermittent has been raising in intermittency due to some change on the
Firefox side, but I kept hitting this failure locally on macos artifiacts debug buils consistently when
using --verify even when I went month back in mozilla-central revisions, which seems to suggest that
this particular intermittent failure have been around for a while and increased in frequency either
for some small timing changes that increased the change of hitting it in a debug build (either on the
Firefox or macOS windows management side), which is not going to be easy to confirm or bisect precisely.
Interestingly when the same test file runs locally on macos using --headless along with --verify, the test
is passing consistently (which makes me thing that the issue may be hit because a browser window created
as fullscreen may be transitioning to fullscreen state asynchronously enough to not be always be in fullscreen
mode by the time browser.window.create resolves the new window details and we hit the intermittent assertion
failure).
As an alternative to skip the entire test file on macos debug builds, this patch includes
a small change to the test case that makes sure that if the test is running on macos and the
new window state is not fullscreen as requested, it wait until it gets to the fullscreen state.
This change was enough to pass --verify locally on macos, and so it also confirms that the newly created
window is getting to the fullscreen state at some point even when it wasn't yet in the fullscreen state
by the time browser.windows.create resolves.
Differential Revision: https://phabricator.services.mozilla.com/D169108
This patch attempts to fix intermittent failures by:
1. using `ensureMaximizedWindow()` where appropriate. While nothing
seemed wrong per se with the previous approach, resizing to the
original height was done to restore the previous window dimensions.
Since the window is maximized before, it makes sense to reuse this
helper function, especially given that it is a bit more robust than
just awaiting an event.
2. not awaiting the `resize` event, which does not seem to be fired all
the time when `resizeBy()` is used. It was mostly fine, except when
it wasn't... Since we have a `.waitForCondition()` call right after,
we can probably skip the await of this event.
Differential Revision: https://phabricator.services.mozilla.com/D169088
If a new network request is performed because when the cache wins
(either a revalidation, or because the cache entry is not complete) we need to
clear mRaceCacheWithNetwork so the network response is not ignored.
Differential Revision: https://phabricator.services.mozilla.com/D169065
This is complicated because we have two thread count values here, because we
want to be able to change the marking thread count for experiments without
changing anything else.
The patch refactors thread related GC parameters into their own set/reset
methods so we can common up the updates that need to happen at the end. Then we
take care to expand the thread pool to the max of the two values, set the
helper thread system's maximum parallel GC tasks setting and update all our
counts based on the actual number of threads we end up with.
Differential Revision: https://phabricator.services.mozilla.com/D169061
This helps the offscreen-canvas measurements done by pdf.js to more closely match the
invisible text layer (used for search/selection/etc) in cases where the host system
locale is non-English and has different generic font prefs (e.g. Japanese).
(Not readily testable in CI because it'll only make a visible difference to behavior
when running with a system locale that has different font prefs.)
Differential Revision: https://phabricator.services.mozilla.com/D169136
Introduce a per-process bytecode-deduplication table for use by off-main-thread
JS parsing. Parsing on the main-thread continues to use the per-JSRuntime table
but no longer needs to worry about locks.
Worker runtimes (with a parent JSRuntime) no longer get their own table and
instead use the per-process table since they are less sensitive to the
performance of the lock. This increases sharing opportunity (for memory
reduction) available to Workers.
Differential Revision: https://phabricator.services.mozilla.com/D168767
