This patch has no observable changes, other than printing deprecation
messages when browser_style is effectively true in MV3.
This patch does include the full logic for all stages of the deprecation
process behind prefs, which will follow the schedule described at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1827910#c1.
All combinations of these prefs are fully covered by unit tests in
toolkit/components/extensions/test/xpcshell/test_ext_browser_style_deprecation.js
The next test tasks confirm the behavior of the current patch:
- browser_style_never_deprecated_in_MV2
- supported_with_browser_style_false
- supported_with_browser_style_true
- supported_with_mv2_defaults
Differential Revision: https://phabricator.services.mozilla.com/D176811
This patch has no observable changes, other than printing deprecation
messages when browser_style is effectively true in MV3.
This patch does include the full logic for all stages of the deprecation
process behind prefs, which will follow the schedule described at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1827910#c1.
All combinations of these prefs are fully covered by unit tests in
toolkit/components/extensions/test/xpcshell/test_ext_browser_style_deprecation.js
The next test tasks confirm the behavior of the current patch:
- browser_style_never_deprecated_in_MV2
- supported_with_browser_style_false
- supported_with_browser_style_true
- supported_with_mv2_defaults
Differential Revision: https://phabricator.services.mozilla.com/D176811
This removes `UrlbarProvider.pickResult()` and `blockResult()` in favor of
handling picks and dismissals through `onEngagement()`. A number of providers
use those two methods, so this revision touches a lot of files.
Handling dismissals through `onEngagement()` means `UrlbarInput.pickResult()`
can no longer tell whether a result is successfully dismissed, so it can't
remove the result anymore. (Maybe `onEngagement()` could return some value
indicating it dismissed the result, but I don't want to go down that road.)
Instead, I split `UrlbarController.handleDeleteEntry()` into two methods: a
public one that removes the result and notifies listeners, and a private one
that handles dismissing the selected result internally in
UrlbarController. Providers that have dismissable results should now implement
`onEngagement()` and call `controller.removeResult()`.
I made some other improvements to engagement handling. There's still room for
more but this patch is big enough already.
Other notable changes:
Include the engaged result in engagement notifications so providers have easy
access to it and can respond to clicks and dismissals more easily. That also
lets us stop passing `selIndex` and `provider` to `engagementEvent.record()`
since now it can compute those from the passed-in result.
Add the concept of `isSessionOngoing` to engagement notifications so providers
can tell whether an engagement ended the search session. Right now, providers
like quick suggest that record a bunch of provider-specific legacy telemetry
assume that `onEngagement()` ends the session, but that's no longer true.
Unify result buttons and result menu commands by setting
`element.dataset.command` on buttons (hopefully we can remove buttons soon, at
least the ones that aren't tip buttons)
Make sure we always notify providers on engagement even on dismissals or
when skipping legacy telemetry
Move dismissal of restyled search suggestions and history results from
`UrlbarController.handleDeleteEntry()` to the Places provider
Move dismissal of form history results from
`UrlbarController.handleDeleteEntry()` to the search suggestions provider
In the Places provider, remove the unused `_addSearchEngineMatch()` method. Also
remove the code in the "searchengine" case that creates a non-search-history
result. This code is unreached because the only time the provider creates a
"searchengine" match it also sets `isSearchHistory` to true.
In `UrlbarTestUtils.promiseAutocompleteResultPopup()`, change the default value
of the `fireInputEvent` param from false to true. This is necessary because
without a starting input event, the start event info in `engagementEvent` will
be null, so when `engagementEvent.record()` is called at the end of the
engagement, it will bail, and providers will not be notified of the engagement.
IMO true is a better default value anyway because input events will typically be
fired when the user performs a search.
Differential Revision: https://phabricator.services.mozilla.com/D174941
It looks like `extension.iconURL` never worked. I added a `getPreferredIcon()`
that relies on `IconDetails.getPreferredIcon()` under the hood in order to
easily get icon URLs from an instance of an `Extension`. I updated a few places
where using this new method is a bit better.
Differential Revision: https://phabricator.services.mozilla.com/D173158
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
`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
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
- 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
And make callers rely on that instead of allowInheritPrincipal when
creating lazy tabs.
Unlike allowInheritPrincipal, skipLoad sets the nodefaultsrc attribute.
This avoids a load instead of falling back to about:blank.
One consequence of that is that switching to a lazy about:blank tab will
not notify invoke listeners registered with addTabsProgressListener
(listeners registered with addProgressListener will still be invoked).
Thus test browser_open_in_lazy_tab.js needs to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D166012
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
Currently we are sending some values, such as principals, from the content
process when creating a nsContextMenu. This information is already available in
the parent process on WindowGlobalParent, so changes the code to fetch the
values from there instead.
Differential Revision: https://phabricator.services.mozilla.com/D161835
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
Currently we are sending some values, such as principals, from the content
process when creating a nsContextMenu. This information is already available in
the parent process on WindowGlobalParent, so changes the code to fetch the
values from there instead.
Differential Revision: https://phabricator.services.mozilla.com/D161835
Makes passing a progress object as part of options more coherent in the
Sanitizer, so we don't need to null check it everywhere.
Create a sub progress object for each cleaner, so they don't overwrite each
other reusing the same property names (like "step"), since all the cleaners are
started in parallel.
Add a few steps to the history cleaner.
This also fixes a typo in the openWindows cleaner, that should receive an object
rather than a string as second argument. Adding a test for this feature is not
trivial, thus I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1803174.
Differential Revision: https://phabricator.services.mozilla.com/D163352
This makes a couple of large changes:
(1) "Generic" buttons (the ones added by `UrlbarView.#addRowButton()`) are now
supported in all row types. The help button that's currently included in some
types of rows when `result.payload.helpUrl` is defined is now supported for all
row types, and two additional button types are now supported too: block buttons
and labeled buttons. A row will get a block button if its
`result.payload.isBlockable` is defined. It will get a labeled button if
`result.payload.buttons` is defined and non-empty. A button can include a `url`
property that is then added as an attribute on the button's element, and
`UrlbarInput.pickResult()` will use this attribute to load the URL when the
button is picked.
(2) The reason I added labeled buttons is because it lets us support tip buttons
without much more effort, which then lets us get rid of the special row type
used for tips. With this patch, tips are now standard rows that use generic
buttons.
This approach should be compatible with the result menu, when we switch over to
it, because we can include the help and block commands in the menu when
`helpUrl` and `isBlockable` are defined, instead of creating buttons for them.
Labeled buttons -- the ones used in tips -- would still be created. The result
menu button itself can continue to be a generic button.
It should also be compatible with including the result menu button inside the
row selection. We'll still add buttons to `.urlbarView-row`, separate from
`.urlbarView-row-inner`, so that the buttons can continue to be on the right
side of the row. We can color the background of the row instead of the
row-inner.
As with D163630, my motivation for this change is to support generic buttons in
dynamic result rows so that help and block buttons can be easily added to
weather suggestions. Here too the larger changes of supporting generic labeled
buttons and removing special rows for tips aren't strictly necessary, but I took
the opportunity to rework things.
Finally, this makes a few other changes:
* It includes some of the more minor improvements to selection that I made in
D163630.
* It removes the help URL code from quick actions since it was decided not to
show a help button. Currently, the button is hidden in CSS, but now that a
generic help button is added for dynamic result rows when
`result.payload.helpUrl` is defined, `helpUrl` needs to be removed from the
payload to prevent a button from being added.
* I removed the special tip wrapping behavior, where the tip button and help
button would wrap below the tip's text. Instead, now the text wraps inside
row-inner and the buttons always remain on the same horizontal as the text. I
don't think it's worth the extra complication.
Differential Revision: https://phabricator.services.mozilla.com/D163766
This makes a couple of large changes:
(1) "Generic" buttons (the ones added by `UrlbarView.#addRowButton()`) are now
supported in all row types. The help button that's currently included in some
types of rows when `result.payload.helpUrl` is defined is now supported for all
row types, and two additional button types are now supported too: block buttons
and labeled buttons. A row will get a block button if its
`result.payload.isBlockable` is defined. It will get a labeled button if
`result.payload.buttons` is defined and non-empty. A button can include a `url`
property that is then added as an attribute on the button's element, and
`UrlbarInput.pickResult()` will use this attribute to load the URL when the
button is picked.
(2) The reason I added labeled buttons is because it lets us support tip buttons
without much more effort, which then lets us get rid of the special row type
used for tips. With this patch, tips are now standard rows that use generic
buttons.
This approach should be compatible with the result menu, when we switch over to
it, because we can include the help and block commands in the menu when
`helpUrl` and `isBlockable` are defined, instead of creating buttons for them.
Labeled buttons -- the ones used in tips -- would still be created. The result
menu button itself can continue to be a generic button.
It should also be compatible with including the result menu button inside the
row selection. We'll still add buttons to `.urlbarView-row`, separate from
`.urlbarView-row-inner`, so that the buttons can continue to be on the right
side of the row. We can color the background of the row instead of the
row-inner.
As with D163630, my motivation for this change is to support generic buttons in
dynamic result rows so that help and block buttons can be easily added to
weather suggestions. Here too the larger changes of supporting generic labeled
buttons and removing special rows for tips aren't strictly necessary, but I took
the opportunity to rework things.
Finally, this makes a few other changes:
* It includes some of the more minor improvements to selection that I made in
D163630.
* It removes the help URL code from quick actions since it was decided not to
show a help button. Currently, the button is hidden in CSS, but now that a
generic help button is added for dynamic result rows when
`result.payload.helpUrl` is defined, `helpUrl` needs to be removed from the
payload to prevent a button from being added.
* I removed the special tip wrapping behavior, where the tip button and help
button would wrap below the tip's text. Instead, now the text wraps inside
row-inner and the buttons always remain on the same horizontal as the text. I
don't think it's worth the extra complication.
Differential Revision: https://phabricator.services.mozilla.com/D163766
This makes a couple of large changes:
(1) "Generic" buttons (the ones added by `UrlbarView.#addRowButton()`) are now
supported in all row types. The help button that's currently included in some
types of rows when `result.payload.helpUrl` is defined is now supported for all
row types, and two additional button types are now supported too: block buttons
and labeled buttons. A row will get a block button if its
`result.payload.isBlockable` is defined. It will get a labeled button if
`result.payload.buttons` is defined and non-empty. A button can include a `url`
property that is then added as an attribute on the button's element, and
`UrlbarInput.pickResult()` will use this attribute to load the URL when the
button is picked.
(2) The reason I added labeled buttons is because it lets us support tip buttons
without much more effort, which then lets us get rid of the special row type
used for tips. With this patch, tips are now standard rows that use generic
buttons.
This approach should be compatible with the result menu, when we switch over to
it, because we can include the help and block commands in the menu when
`helpUrl` and `isBlockable` are defined, instead of creating buttons for them.
Labeled buttons -- the ones used in tips -- would still be created. The result
menu button itself can continue to be a generic button.
It should also be compatible with including the result menu button inside the
row selection. We'll still add buttons to `.urlbarView-row`, separate from
`.urlbarView-row-inner`, so that the buttons can continue to be on the right
side of the row. We can color the background of the row instead of the
row-inner.
As with D163630, my motivation for this change is to support generic buttons in
dynamic result rows so that help and block buttons can be easily added to
weather suggestions. Here too the larger changes of supporting generic labeled
buttons and removing special rows for tips aren't strictly necessary, but I took
the opportunity to rework things.
Finally, this makes a few other changes:
* It includes some of the more minor improvements to selection that I made in
D163630.
* It removes the help URL code from quick actions since it was decided not to
show a help button. Currently, the button is hidden in CSS, but now that a
generic help button is added for dynamic result rows when
`result.payload.helpUrl` is defined, `helpUrl` needs to be removed from the
payload to prevent a button from being added.
* I removed the special tip wrapping behavior, where the tip button and help
button would wrap below the tip's text. Instead, now the text wraps inside
row-inner and the buttons always remain on the same horizontal as the text. I
don't think it's worth the extra complication.
Differential Revision: https://phabricator.services.mozilla.com/D163766
