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 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
`this.forNode` (with `this` being a `PanelMultiView` instance) may
return a node that was already disconnected before, in which case its
`node` member will be void. To avoid unexpected promise rejections, add
a null check before `_moveOutKids()`.
Differential Revision: https://phabricator.services.mozilla.com/D167369
- Explicitly wait for popup close (via port.onDisconnect) before
checking whether the popup is closed.
- On --headless (MOZ_HEADLESS), explicitly close the popup since that
does not automatically happen for some unknown reason. Test case:
./mach test browser/components/extensions/test/browser/browser_ext_incognito_views.js --headless
- Explicitly wait for popup close (via port.onDisconnect) before
closing the final private window. While this is mainly meant as
a work-around for bug 1800100, it also helps with reducing the
impact of bug 1811071 (follow up in bug 1811459).
Differential Revision: https://phabricator.services.mozilla.com/D167190
