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
Bug 1323311 tried to improve browser.tabs.move, but the logic didn't
really make sense (e.g. why use 2 different maps to track indices?),
and it broke moving multiple tabs between windows: they would appear
in the wrong order.
Differential Revision: https://phabricator.services.mozilla.com/D166405
This patch removes the use of the "unified extensions" pref and adjust
the existing tests. More clean-ups will be done in follow-ups, e.g. the
removal of `gUnifiedExtensions.isEnabled` and some test-only changes to
no longer create a new window in each test file.
Differential Revision: https://phabricator.services.mozilla.com/D166908
In order to handle the content script case correctly we must expose the
contentScriptAddonPolicy to JavaScript. With that we can always see what
extension is trying to perform an action and use its name rather than internal
ID in the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D161282
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
