Fix the margins on the zoom indicator, so that it's as tall as other icons.
Style the zoom indicator as an urlbar chiclet in Proton.
Add hover and active states to the zoom indicator and the identity-box in Proton.
Fix the center alignment of the cfr label.
Differential Revision: https://phabricator.services.mozilla.com/D108920
Fix the margins on the zoom indicator, so that it's as tall as other icons.
Style the zoom indicator as an urlbar chiclet in Proton.
Add hover and active states to the zoom indicator and the identity-box in Proton.
Fix the center alignment of the cfr label.
Differential Revision: https://phabricator.services.mozilla.com/D108920
This patch sets `color` in arrowpanels and the address bar to the appropriate Proton color. It adds a --blue-tint variable that tints the fallback buttons-secondary-bgcolor variables. Those variables are now also used for arrowpanel colors, which reflects how the Proton spec uses consistent hover/pressed colors throughout. The arrowpanel colors get more opaque in Proton, which reflects the darker colours used on the spec. A new variable, --urlbar-result-hover-bgcolor, is introduced. This is necessary because the Proton spec makes an exception for the result hover bgcolor in the Light Mode Urlbar, where it's Secondary instead of Secondary Hover.
Differential Revision: https://phabricator.services.mozilla.com/D107562
List of requested changes and resolutions:
List item height looks shorter than spec. List height should 36px and hover state height should be 32px. URL bar in closed state/default state should be 32px tall.
- List height addressed. Urlbar height addressed in D107422.
The bottom “This time, search with:” row height looks taller than the spec.
- Addressed.
The colour on the “Selected” and “Hover” state looks inverted. The colour for hover/pressed states should be universal in the browser. The “Selected” state is using “Secondary” in the colour palette.
- I spoke with UX and we're going with Secondary Hover for hover and Secondary Pressed for selected. I moved this into a second patch since I expect it will require more review/UX discussion.
Can you confirm if the hairline colour is from the spec? It looks a bit dark. Hairline colours should be the same across the browser and should be using “Secondary” in the colour palette (F0F0F4).
- Changed to F0F0F4.
The “This time search with:” favicons are missing pressed states - These should be the same as list item hover/pressed states (see above spec link)
- Colour changes are included in Part 2. Adding an :active state may require more engineering effort than is scoped for this bug. In SearchOneOffs._on_mousedown, we [call event.preventDefault()](https://searchfox.org/mozilla-central/rev/9bf82ef9c097ee6af0e34a1d21c073b2616cc438/browser/components/search/SearchOneOffs.jsm#1154). This means an :active state is not set on the buttons, so we can't have a separate pressed/:active state. I confirmed that line is still needed on Linux to get catch clicks. We could gate it behind a platform check so at least we have an :active state on macOS and Windows, but the slight behaviour change might cause headaches in the future. I left it as-is for now.
Please remove the green text for “Search with Google”. All green text should be updated to match standard text on light theme colour (#15141A).
- Addressed.
Remove vertical hairline between the Shield/Lock icon in the URL bar.
- Addressed in 1691531.
Update the URL Focused state on New Tab to have 40% opacity on the blue border (#0061E0, 40%)
- Addressed.
Differential Revision: https://phabricator.services.mozilla.com/D107561
We use it for the awesomebar outline so I think it makes sense, it certainly
feels off to have a blue tab line but an accent-colored outline.
Differential Revision: https://phabricator.services.mozilla.com/D107626
This patch changes the selection colour in the Urlbar view. It only changes the colours when a theme is not applied, to not break the many themes that depend on the panel background/color being Highlight/HighlightText. It also only changes the default theme on macOS and the default Windows theme. Windows High Contrast and Linux OS themes would break if the autocomplete background was not Highlight.
This patch also reduces the padding in the search one-offs and changes the color of arrowpanel-dimmed slightly to better match the spec. The hover colour shown in the spec is rgb(240,240,244). The new arrowpanel-dimmed colour is rgb(240,240,240).
Differential Revision: https://phabricator.services.mozilla.com/D105535
`appearance` CSS rules allow elements to take on system appearance. For UI elements that we want to take on system styling, we set `appearance: auto` combined with platform-specific rules like `-moz-default-appearance: -moz-mac-vibrant-titlebar-light;`
macOS sidebar vibrancy broke because a background-color was being applied to `root`. That colour appeared under elements with `appearance: auto` set, so we wouldn't see the platform-specific styling. This patch moves the root background-color to `#navigator-toolbox`, so that it does not appear under `#sidebar-box`.
We still want a background colour applied to sidebars when a lwtheme includes one. We only want `appearance: auto` applied to sidebars when the active theme does not have sidebar styling rules. That's why `#sidebar-box:not(:-moz-lwtheme)` is changed to `#sidebar-box:not([lwt-sidebar])`.
This patch also removes the rule
```
:root:-moz-lwtheme {
appearance: none;
}
```
from osx/global/global.css. There's no corresponding addition of a `#navigator-toolbox { appearance:none; }` rule because that rule already exists in [osx/browser.css](https://searchfox.org/mozilla-central/rev/7067bbd8194f4346ec59d77c33cd88f06763e090/browser/themes/osx/browser.css#45).
Differential Revision: https://phabricator.services.mozilla.com/D104416
Uses of `-moz-appearance: none` are changed to `appearance: none`.
Uses of other values that are simply reverting the appearance back to
its default are changed to `appearance: auto`.
Uses of values in UA sheets that are defining the inherent appearance of
widgets are changed to:
appearance: auto;
-moz-default-appearance: <value>;
since those values are either no longer supported on (-moz-)appearance,
or are still supported but only in some limited form.
There are some uses of `-moz-appearance: textfield` on <input
type=number> elements that are renamed to `appearance: textfield`.
Differential Revision: https://phabricator.services.mozilla.com/D83430
This is needed because under the new vibrancy model, vibrant -moz-appearance
values only work on elements that have nothing rendered behind them. The elements
with the vibrant appearance become truly transparent.
Differential Revision: https://phabricator.services.mozilla.com/D51465
This is preferable over a hardcoded color because it lets Gecko choose where the
window background should come from. We would like the background to be handled
by the OS widget, and prevent Gecko from painting a CSS background color.
Differential Revision: https://phabricator.services.mozilla.com/D51460
smolnar
Jared Wein
Emma Malysz
Marco Bonardo
Bogdan Tara
Harry Twyford
Mark Striemer
Alexandru Michis
Tim Nguyen
Emilio Cobos Álvarez
Mike Conley
Yura Zenevich
Magnus Melin
Dão Gottwald
Kartik Gautam
Micah Tigley
Dorel Luca
Gijs Kruitbosch
Itiel
Cameron McCormack
Markus Stange
Brindusan Cristian