I wasn't able to hit this locally even when running the test with --verify, and in the failure logs from the
failures linked to orangefactor I couldn't find any that would provide me some clue of what is going on,
but if the identity box is being updates asynchronously then I would not exclude this may be hit only in
some cases that are never hit locally by executing this test file on its own.
This patch adds a few small changes to explicitly wait for a mutation of the identity box before asserting
the styles, the test was still passing consistently locally and so if this version would fail for
a timeout due to get stuck waiting for the mutation, then we would at least determine that the identity
box would very likely never be updated and there may be something else going on that may be worth digging
further into.
Differential Revision: https://phabricator.services.mozilla.com/D171497
This is a test-only change. It introduces a new Urlbar pref to make the
existing 3000 ms timeout configurable.
That timeout is currently reached 8 times in the test. That means that
the test will take at least 3 x 8 = 24 seconds to run while basically
doing nothing, and makes the test prone to reach the deadline by which
the test is declared timed-out.
To avoid "Test timed out" errors, the test now reduces the fixed 3000 ms
timeout to 500 ms, so now we wait for 8x500 = 4 seconds instead of 24.
Differential Revision: https://phabricator.services.mozilla.com/D169846
In case the user does not have any active extensions listed, if `extensions.getAddons.showPane` is set to true (default), clicking on the unified extensions button will lead to the recommendations section in about:addons. If it is set to false, clicking the button will now lead to the extension list instead of the, disabled by the user, recommendations section.
Differential Revision: https://phabricator.services.mozilla.com/D169570
The screenshot in one of the failed jobs made me think that we should
probably close the browser action popup when we open it.
Differential Revision: https://phabricator.services.mozilla.com/D169636
This also updates layoutdebug.js, which in some ways pretends to be like a browser window but
is its own special snowflake. I kept the method naming conventions similar to the main
browser window.
Depends on D168394
Differential Revision: https://phabricator.services.mozilla.com/D168395
This also updates layoutdebug.js, which in some ways pretends to be like a browser window but
is its own special snowflake. I kept the method naming conventions similar to the main
browser window.
Depends on D168394
Differential Revision: https://phabricator.services.mozilla.com/D168395
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
