I'm not sure off-hand how to test the tab-specific notifications, but
that uses no particular styling so seems it should just work?
Differential Revision: https://phabricator.services.mozilla.com/D233427
As per discussion with UX, we might want the toolbox background to be
different in (some of) our default themes in this case, but that seems
orthogonal, and this seems somewhat straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D227494
* Fix various z-index/paint order issues by making the urlbar a popover - which moves the open
urlbar to the top layer, outside the toolbox
* Adjust the urlbar position when the autohide menubar shows and hides
* Temporarily disable the browser_urlbar_keyed_search.js which needs revisiting to measure reflows under regular, non-test-specific conditions
Combines work from nsharpley and sfoster on top of emilio's original popover patch
Differential Revision: https://phabricator.services.mozilla.com/D224201
* Fix various z-index/paint order issues by making the urlbar a popover - which moves the open
urlbar to the top layer, outside the toolbox
* Adjust the urlbar position when the autohide menubar shows and hides
Combines work from nsharpley and sfoster on top of emilio's original popover patch
Differential Revision: https://phabricator.services.mozilla.com/D224201
- Remove the titlebar-color class which is now redundant with browser-titlebar
- Fix the specificity in the linux stylesheet ensuring titlebar toolbars show the theme's background images not the falback colors
Differential Revision: https://phabricator.services.mozilla.com/D224862
In bug 878551, the ability to move the list-all-tabs button was removed
for a few reasons:
> Moving this widget to the navbar gives it a tiny scaled version of Toolbar.png (like a horizontal line).
> Moving it back to the tab strip make it misbehave. It disappears, but sometimes flickers into view when opening/closing a tab.
These issues are no longer present, so we should be able to allow moving
the list-all-tabs button once again.
Differential Revision: https://phabricator.services.mozilla.com/D224623
In bug 878551, the ability to move the list-all-tabs button was removed
for a few reasons:
> Moving this widget to the navbar gives it a tiny scaled version of Toolbar.png (like a horizontal line).
> Moving it back to the tab strip make it misbehave. It disappears, but sometimes flickers into view when opening/closing a tab.
These issues are no longer present, so we should be able to allow moving
the list-all-tabs button once again.
Differential Revision: https://phabricator.services.mozilla.com/D224623
In bug 878551, the ability to move the list-all-tabs button was removed
for a few reasons:
> Moving this widget to the navbar gives it a tiny scaled version of Toolbar.png (like a horizontal line).
> Moving it back to the tab strip make it misbehave. It disappears, but sometimes flickers into view when opening/closing a tab.
These issues are no longer present, so we should be able to allow moving
the list-all-tabs button once again.
Differential Revision: https://phabricator.services.mozilla.com/D224623
* Remove the #titlebar element, and ensure toolbars that comprise the titlebar get a .browser-titlebar class
* Ensure we call TabBarVisibility.update when initializing with verticalTab=true
* Adjust TabBarVisibility logic so we allow for the vertical tabs case
* Give #navigator-toolbar z-index: var(--browser-area-z-index-toolbox) to ensure the urlbar view doesnt get clipped behind the lower elements
Differential Revision: https://phabricator.services.mozilla.com/D222059
* Remove the #titlebar element, and ensure toolbars that comprise the titlebar get a .browser-titlebar class
* Ensure we call TabBarVisibility.update when initializing with verticalTab=true
* Adjust TabBarVisibility logic so we allow for the vertical tabs case
* Give #navigator-toolbar z-index: var(--browser-area-z-index-toolbox) to ensure the urlbar view doesnt get clipped behind the lower elements
Differential Revision: https://phabricator.services.mozilla.com/D222059
* Remove the #titlebar element, and ensure toolbars that comprise the titlebar get a .browser-titlebar class
* Ensure we call TabBarVisibility.update when initializing with verticalTab=true
* Adjust TabBarVisibility logic so we allow for the vertical tabs case
* Give #navigator-toolbar z-index: var(--browser-area-z-index-toolbox) to ensure the urlbar view doesnt get clipped behind the lower elements
Differential Revision: https://phabricator.services.mozilla.com/D222059
Also move sidebar padding into tabs from the container, show scrollbar
gutter with non-overlay scrollbars, prevent icon shifting when expanding
the sidebar, avoid cropping tab background shadows.
Co-authored-by: Tim Giles <tgiles@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D222659
The main purpose of this patch is to make the visibility of the revert button consistent to make it more accessible. After talking with Josh, we agreed the revert icon should always show in an `invalid` pageproxystate until `userTypedValue` differs from the search string. Doing so will make the Revert button be more predictable for keyboard users instead of hiding it when the input field is focused and then showing it again when they press tab (or not making it focusable at all).
The Go button (the right arrow button) will show up again once the user has modified the search terms. I didn't think this would be much of an issue since the Go arrow is not focusable by keyboard, it's not visible when the address bar is not focused, and "Enter" is a well known shortcut to doing the same function.
This involved checking when `persistsearchterms` was changed to `false` and removing it to instead remove `persistsearchterms` when the search terms changed. This is reflected in the new expected behavior in the tests.
One issue was adding `focus` to the revert button via CSS caused focus issues. Tabbing from the left elements (reload button) to the input would skip the input altogether and go straight to the revert button and then to the Save to Pocket button. Pressing shift + tab to try and go back from the revert button to the input would get stuck in a loop between the input field and revert button. This was fixed with `<toolbartabstop/>` . I created a hideable container to ensure the tabstop only exists when the `persistsearchterms` state is active. And the new test checks that the tab behaviour is consistent.
Lastly, because keyboard users might press the Revert button, focusing the input seemed like a logical choice, or else when the focus is lost the user would need to tab all the way back to the input to do more actions. There is also an initiative to move inline Javascript out from markup.
Differential Revision: https://phabricator.services.mozilla.com/D223423
