In particular, this makes it so that Proton PopupNotifications:
* Are ~400px wide (but use an em value for system font flexibility)
* Use a slightly larger font on macOS
* Have a 16px padding, regardless of platform
* Has 16px of space between each popupnotificationcontent, and before
the popup-notification-checkbox.
* Sets a default font-weight on the WebRTC permission panel label when
a single device label is listed
Differential Revision: https://phabricator.services.mozilla.com/D108518
In particular, this makes it so that Proton PopupNotifications:
* Are ~400px wide (but use an em value for system font flexibility)
* Use a slightly larger font on macOS
* Have a 16px padding, regardless of platform
* Has 16px of space between each popupnotificationcontent, and before
the popup-notification-checkbox.
* Sets a default font-weight on the WebRTC permission panel label when
a single device label is listed
Differential Revision: https://phabricator.services.mozilla.com/D108518
* Switch from :active to :hover:active for consistency with OS, and to fix common.css bug
* Tweak hover/active feedback (I guess those values are slightly opinionated towards certain themes, but should be better than nothing)
* Disable custom what's new panel checkbox styling when proton is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D108349
I also noticed while trying out this patch that the context menu navigation
icons really need to also scale with the font size, so I've fixed that here
along with the submenu arrows.
Differential Revision: https://phabricator.services.mozilla.com/D107570
Otherwise with some fonts the menus look off. This doesn't change visual
appearance with the default font, afaict (but I don't have such a good eye so
please double-check).
Maybe we should do this only for the content select dropdown, but then again my
untrained eye doesn't see an issue for other menuitems either so...
Differential Revision: https://phabricator.services.mozilla.com/D107630
Otherwise with some fonts the menus look off. This doesn't change visual
appearance with the default font, afaict (but I don't have such a good eye so
please double-check).
Maybe we should do this only for the content select dropdown, but then again my
untrained eye doesn't see an issue for other menuitems either so...
Depends on D107629
Differential Revision: https://phabricator.services.mozilla.com/D107630
The Linux styles match Adwaita trunk[1], so it's a bit smaller than the
native ones but I think that's fine (it matches other themes more
closely, like Arc).
On OSX the system color needs to be tweaked (will do in a follow-up)
since it is windows-style yellow right now, which is rather ugly. But
this is a progression regardless.
[1]: https://gitlab.gnome.org/GNOME/gtk/-/issues/3352
Differential Revision: https://phabricator.services.mozilla.com/D107548
This was originally added in bug 1120967 to space the help button that used to appear in the header. The help button has since been removed.
It's bogus in this case, because it accidentally overrides the display value of some description (which used to force their own display value).
Differential Revision: https://phabricator.services.mozilla.com/D107334
This uses the new sizeTo value supported by SubDialog.jsm to also impact
how we size things inside the dialog. It's a bit complicated because we
need the dialog to support 3 layouts:
1. the window-modal setup (which we're trying not to touch)
2. the non-proton modal setup (which uses grid layout to have one column with
the image and the username/password fields, where applicable)
3. the proton modal setup (where we don't want the grid layout, as
the labels for username/password go above their text fields and there's no
big icon on the left, so there's no point)
Finally, for content modal prompts, we need to effectively determine the size
of the content and whether we need to overflow. We can't just always allow
flexbox to shrink everything, or we end up with overflow even for dialogs
with just 2 lines of text.
So with this patch, we determine the ideal height of the dialog document from
SubDialog.jsm, before setting the `.sizeDetermined` class there, thus allowing
the #infoBody part to overflow. The SubDialog.jsm code will ensure the
embedding browser is large enough to allow not overflowing/scrolling the
content.
In terms of the 3 layouts, we select for "not 1" by using `dialog[subdialog]`
(an attribute set by the SubDialog.jsm code anyway). We then use proton
pref-based @supports queries to pick between layouts (2) and (3).
Differential Revision: https://phabricator.services.mozilla.com/D107111
This moves some inline styles into CSS and fixes modal masks and shadows to match the spec.
I also noticed some negative effects from other Proton button styles on close-icon buttons in dialogs
in about:preferences (e.g. check the oversized titlebar for the fonts dialog) that I fixed here.
Differential Revision: https://phabricator.services.mozilla.com/D107109
It was clarified that the percentages are weights, and two weights are
now allowed. Missing percentages are computed as 100% - the other or
50%. Other than that, commas are required etc, which is good since
that's how I implemented it originally.
Differential Revision: https://phabricator.services.mozilla.com/D107295
CLOSED TREE
Backed out changeset 0580aaec32a0 (bug 1693277)
Backed out changeset be8108cd9820 (bug 1693277)
Backed out changeset 8b9986d057d7 (bug 1693277)
This uses the new sizeTo value supported by SubDialog.jsm to also impact
how we size things inside the dialog. It's a bit complicated because we
need the dialog to support 3 layouts:
1. the window-modal setup (which we're trying not to touch)
2. the non-proton modal setup (which uses grid layout to have one column with
the image and the username/password fields, where applicable)
3. the proton modal setup (where we don't want the grid layout, as
the labels for username/password go above their text fields and there's no
big icon on the left, so there's no point)
Finally, for content modal prompts, we need to effectively determine the size
of the content and whether we need to overflow. We can't just always allow
flexbox to shrink everything, or we end up with overflow even for dialogs
with just 2 lines of text.
So with this patch, we determine the ideal height of the dialog document from
SubDialog.jsm, before setting the `.sizeDetermined` class there, thus allowing
the #infoBody part to overflow. The SubDialog.jsm code will ensure the
embedding browser is large enough to allow not overflowing/scrolling the
content.
In terms of the 3 layouts, we select for "not 1" by using `dialog[subdialog]`
(an attribute set by the SubDialog.jsm code anyway). We then use proton
pref-based @supports queries to pick between layouts (2) and (3).
Differential Revision: https://phabricator.services.mozilla.com/D107111
This moves some inline styles into CSS and fixes modal masks and shadows to match the spec.
I also noticed some negative effects from other Proton button styles on close-icon buttons in dialogs
in about:preferences (e.g. check the oversized titlebar for the fonts dialog) that I fixed here.
Differential Revision: https://phabricator.services.mozilla.com/D107109
certviewer.html, being a toolkit file, shouldn't link to an icon in browser. This results in a broken image icon in Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D107166
`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
Reduces the uneven spacing from the icons, and the weight of the shadow (while keeping some of it, so it still looks over like part of browser chrome).
Differential Revision: https://phabricator.services.mozilla.com/D106070
The background change matches Windows / Mac, and common sense too.
The customoptionstyling change is because that comment is just false,
although custom select is not enabled on Linux (though maybe it could
after this patch, will look into it separately).
Finally, give some padding to unthemed menuitems. GTK overrides this
padding with the theme one, but this allows having a sane default.
This is the padding I get with Adwaita, which is the default GTK theme.
Differential Revision: https://phabricator.services.mozilla.com/D104874
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
This widget will be used for the profiler button. The profiler button is a
two-part widget with both a command and a view. The command starts/stops the
profiler, but the starting/stopping can also be performed from inside the view.
The dropmarker button shows the view.
When this widget is located in the panel, the start/stop action is only
accessible via the view and there is no "quick-action" command.
The structure of the widget is as follows:
toolbaritem.toolbaritem-combined-buttons
- toolbarbutton.toolbarbutton-1
- toolbarbutton.toolbarbutton-1.toolbarbutton-combined-buttons-dropmarker
The dropmarker icon is the toolbarbutton icon of the second toolbarbutton.
The dropmarker button is only shown in the toolbar or in the customize palette.
It is hidden when the widget is located in the panel.
In the toolbar, the hover effect of the dropmarker needs to have the same height
as the hover effect of the regular button. However, due to the different image
size (12x12 instead of 16x16) it requires more vertical padding.
Differential Revision: https://phabricator.services.mozilla.com/D98216
Adding a check for updates option to the application menu, changing the about dialog styling to match the mockup, and adding a minimum delay to the checking for updates message.
Differential Revision: https://phabricator.services.mozilla.com/D95195
Adding a check for updates option to the application menu, changing the about dialog styling to match the mockup, and adding a minimum delay to the checking for updates message.
Differential Revision: https://phabricator.services.mozilla.com/D95195
* Move shared open-in-new and print icons into toolkit and update references
* The pendingpaint.png reference will be removed in bug 1679133
Differential Revision: https://phabricator.services.mozilla.com/D101239
- update menu to be horizontal and padded on mobile to give tables more space
- improve font size in menu and inputs
- hide title on mobile
- misc. style changes
Differential Revision: https://phabricator.services.mozilla.com/D99551
The new section is displayed when the browser.enableAboutThirdParty pref is true.
This is a prototype of the project where we plan to disclose third-party modules
info to the users. Once we find out what is the best place and the best way to
show these data, we remove this section.
Differential Revision: https://phabricator.services.mozilla.com/D93832
Mike Conley
Bogdan Tara
Tim Nguyen
Butkovits Atila
Gijs Kruitbosch
Cosmin Sabou
Brindusan Cristian
Dão Gottwald
Csoregi Natalia
Noemi Erli
smolnar
Micah Tigley
Alexandru Michis
leli
Erica Wright
Molly Howell
Emilio Cobos Álvarez
Narcis Beleuzu
Geoff Lankow
Julien Wajsberg
Neil Deakin
Jared Wein
harry
Itiel
Yura Zenevich
Magnus Melin
Swapnik Katkoori
Tony Froman
Abhishek Sharma
Dorel Luca
Markus Stange
Bernard Igiri
Sam Foster
Andrei Cristian Petcu
Kartik Gautam
Sonia Singla
Zeid Zabaneh
Toshihito Kikuchi