I'm a bit baffled about bug 1789877. My best theory so far is that we're
inserting the element a bit deeper in the DOM and that causes us to
reflow slightly more stuff when tab-switching, but...
In any case while going through the code the status panel can be
simplified a bit now, so do that.
Differential Revision: https://phabricator.services.mozilla.com/D156876
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
Also, align them properly.
The issue is that we inherit the region margin introduced in bug 1772507, but
we were styling the panel in a way that causes the region to not match the
shadow size.
Simplify a bit the styling so that all the margins add up.
For uplift it'd be simpler to just set the new property to zero, I'll prepare a
patch for that. That would cause the shadows to count as popup contents, but
that's the pre-103 behavior which seems fine.
Differential Revision: https://phabricator.services.mozilla.com/D153856
Both Chrome and Edge on Windows also move the swipe-to-nav arrow icon, the
distance of move seems to be a fixed value, it doesn't depend on the browser
window size. So we also use a fixed value, 100px here.
Chrome on Mac also moves the icon, but in a slightly different way. The icon is
a semicircle shape, it never leaves the edge of the browser window even if it's
moving during swipe gestures. So we introduce a new preference named
"browser.swipe.navigation-icon-move-distance" to implement platform dependent
swipe-to-nav icon behaviors. As of now the value on platforms other than Windows
is zero so that the icon never moves on the platforms.
Depends on D152951
Differential Revision: https://phabricator.services.mozilla.com/D150433
Both Chrome and Edge on Windows also move the swipe-to-nav arrow icon, the
distance of move seems to be a fixed value, it doesn't depend on the browser
window size. So we also use a fixed value, 100px here.
Chrome on Mac also moves the icon, but in a slightly different way. The icon is
a semicircle shape, it never leaves the edge of the browser window even if it's
moving during swipe gestures. So we introduce a new preference named
"browser.swipe.navigation-icon-move-distance" to implement platform dependent
swipe-to-nav icon behaviors. As of now the value on platforms other than Windows
is zero so that the icon never moves on the platforms.
Differential Revision: https://phabricator.services.mozilla.com/D150433
This is closer to what the standard lwt dark mode does, and seems fair
enough. I don't mind much either way so if you feel strongly about it
lmk.
Differential Revision: https://phabricator.services.mozilla.com/D139931
* @import rather than %include stylesheets in each platform's browser.css
* Remove the inc.css suffix for @imported files
* browser.inc.css becomes browser-shared.css
* Move shared @imports to browser-shared.css
* panelUI.inc.css becomes panelUI-shared.css
* download/indicator.inc.css becomes download/indicator.css and is @import-ed.
* addons/extension-controlled.inc.css becomes addons/extension-controlled.css and is @import-ed
* places/places-tooltip.inc.css becomes places/places-tooltip.css and is @import-ed
* urlbar/dynamicResults.inc.css becomes urlbar-dynamic-results.css and is @import-ed from urlbarView.css
* Remove preprocessing flags from css resources in jar.inc.mn that no longer contain any preprocessor directives
Differential Revision: https://phabricator.services.mozilla.com/D140275
On light themes this is basically indiscernible (afaict). On dark themes
this keeps looking good, but it increases the contrast with the accent
color, which in the case of Adwaita-dark is well, pretty dark.
Differential Revision: https://phabricator.services.mozilla.com/D139708
* The menuitem[cmd="cmd_clearhistory"] rules in the linux stylesheet were orphaned by 5d6c747a780c (Bug 1582639) and missed in clean-up.
* Alphabetize the shared manifest files entries.
Differential Revision: https://phabricator.services.mozilla.com/D139552
* The menuitem[cmd="cmd_clearhistory"] rules in the linux stylesheet were orphaned by 5d6c747a780c (Bug 1582639) and missed in clean-up.
* Alphabetize the shared manifest files entries.
Differential Revision: https://phabricator.services.mozilla.com/D139552
I came across this again when trying to address bug 1756676 and figured
I would just address this bug immediately per our previous discussion
on the bug.
Differential Revision: https://phabricator.services.mozilla.com/D139421
* Inline the platform specific rules in a single preferences/dialog.css.
* Inline the platform specific rules in a single preferences/preferences.css.
Note that the linux and windows .actionButtons margins were not in use - the margins from dialog.css were applied and are correct as-is so this override was removed.
* @import rather than %include the usercontext.css in the containers preferences UI
Differential Revision: https://phabricator.services.mozilla.com/D138979
* Rename the shared panel.inc.css to panel.css - making it replace the platform-specific sheet we load at chrome://browser/skin/controlcenter/panel.css
* Linux and Windows stylesheets had duplicated overrides, those are inlined into panel.css at the appropriate spot
* MacOS overrides are placed in context using a @media query.
* Remove the old windows/linux/osx CSS files.
Differential Revision: https://phabricator.services.mozilla.com/D137924
* I've simply expanded/inlined the vars here. They did serve some function in making some selectors a bit more compact, but the result doesn't seem onerous to me. I.e. I think Gijs' concern in the description of this bug isn't warranted in this case.
* More importantly, the @item@ variable included the id of the list container, which used to differ between the download panel and the content/all-downloads view (about:downloads and the library/places view). With that distinction removed in the previous patch, we get straightforward reuse via includes. Figuring out how to get rid of the %includes is bug 1659584.
* Simplify some affected selectors to use :is()
* Use focus-visible rather than -moz-focusring in the windows downloads stylesheet
Differential Revision: https://phabricator.services.mozilla.com/D135401
To do this, we always draw the native titlebar behind the toolbox, and
then make the toolbox adapt to it by using the titlebar radius. This
makes us preserve the shadow properly.
On Wayland we'd double-draw the shadow (see bug 1509931 comment 4) so
this fixes it by trimming it as well using border-radius.
Differential Revision: https://phabricator.services.mozilla.com/D128681
This is based off work by smurfd. But this patch doesn't support buttons
both at the left and right, which simplifies a lot the implementation.
Also, clean-up the existing env variables while at it.
Co-authored-by: Nicklas Boman <smurfd@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D132073
