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
This is a completely redesign based on mconley's idea to use `deck`.
That removes a lot of code and makes things a lot better.
Depends on D163077
Differential Revision: https://phabricator.services.mozilla.com/D162390
It looks like this used to be possible by chance when we didn't check
the event in `togglePanel()`. Now that we do this (to prevent
context-click to open the panel for example), we need to check the event
type and which button or key is clicked/pressed.
Differential Revision: https://phabricator.services.mozilla.com/D163076
Depending on the test chunks on Firefox CI, we might have a test file
executed before this one that resizes the window and does not reset it.
In most cases, this isn't an issue except when we have logic to overflow
extension buttons pinned in the toolbar into the unified extensions
panel. This is what's happening here, at least for some configurations.
By making sure that the window is large enough, we should not have
overflowed extension buttons in the panel anymore. That will make the
test more robust.
Differential Revision: https://phabricator.services.mozilla.com/D162961
We have some internal bookkeeping within OverflowableToolbar to remember the state of things that
have overflowed, like how wide the window needs to be before they can be moved back, etc. When an
item is removed from an overflowable toolbar while overflowed, we update that internal bookkeeping
so that OverflowableToolbar doesn't accidentally try to move those items back into the toolbar
when the window becomes wide enough again.
We've added a new overflow list for extension buttons, but we weren't updating our internal accounting
when items had been overflowed into that list. This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D162434
This will force the panel to close when we click an item in the context
menu, without having to handle each menu item separately.
Differential Revision: https://phabricator.services.mozilla.com/D162424
