This should be an idempotent patch. The way to come up with this patch has been:
* Run the first script attached to the bug and pipe it to xclip, then paste it
in color.rs
* Add the relevant #[derive] annotations and remove the color.mako.rs
definition.
* Reorder the values to match the ColorID definition, on which some widget
prefs and caching stuff relies on.
* Manually port some documentation from nsLookAndFeel.h
* Run `rg 'eColorID_' | cut -d : -f 1 | sort | uniq >files`
* Run the second script attached to the bug.
* Manually fix usage of `LAST_COLOR` (adding the `End` variant), and adding
casts to integer as needed.
* Add an static assert so that people remember to update the prefs, rather than
a comment on the definition :)
Differential Revision: https://phabricator.services.mozilla.com/D32610
--HG--
extra : moz-landing-system : lando
Based on the implementation and issues on prefers-reduced-motion, it
seems we have the same issue on the dark mode.
In child processes on MacOSX we don't spin native event loop at all.
Without native event loops, the global preference returned from
`SystemWantsDarkTheme()` doesn't return up-to-date value when the system
setting changed for some reasons.
To workaround this we call `SystemWantsDarkTheme()` only on the parent
process which spins native event loop or when it's the initial query on
the child process. And we give the up-to-date value to the child process
via an IPC call just like other cached values do.
Differential Revision: https://phabricator.services.mozilla.com/D21303
--HG--
extra : moz-landing-system : lando
The only caller wants CSS pixels, no need to go back and forth.
This is the last dependency on the pres context, I think, from the style system
font code.
Differential Revision: https://phabricator.services.mozilla.com/D19147
The framework to simulate the setting change works as following;
- nsIDOMWindowUtils.setPrefersReducedMotion() calls an IPC function which ends
up calling nsChildView::SetPrefersReducedMotion() in the parent process
- nsChildView::SetPrefersReducedMotion() sets the given value into
nsLookAndFeel::mPrefersReducedMotionCached just like we set the value queried
via NSWorkspace.accessibilityDisplayShouldReduceMotion in the parent process
and send a notification which is the same notification MacOSX sends when the
system setting changed
- Normally the cached value is cleared before quering new values since the
cache value is stale, but in this case the value is up-to-date one, so
nsChildView::SetPrefersReducedMotion() tells that we don't need to clear the
cache, and nsIDOMWindowUtils.resetPrefersReducedMotion() resets that state
of 'we don't need to clear the cache'
There are two test cases with the framework in this commit, one is just setting
the value and checking the value queried by window.matchMedia. The other one is
receiving 'change' event and checking the value of the event target.
Note that to make this test works the patch for bug 1478212 is necessary since
the test runs in an iframe.
Depends on D5003
Differential Revision: https://phabricator.services.mozilla.com/D5004
--HG--
extra : moz-landing-system : lando
In child processes on MacOSX we don't spin native event loop at all.
Without native event loops NSWorkspace.accessibilityDisplayShouldReduceMotion
doesn't return up-to-date value when the system setting changed for some reasons.
To workaround this we use NSWorkspace.accessibilityDisplayShouldReduceMotion
only on the parent process which spins native event loop or when it's the
initial query on the child process. And we give the up-to-date value to the
child process via an IPC call just like other cached values do.
Depends on D5002
Differential Revision: https://phabricator.services.mozilla.com/D5003
--HG--
extra : moz-landing-system : lando
All our widgets support it with a constant true.
MozReview-Commit-ID: JMEItUsxYWq
--HG--
extra : rebase_source : e7e0a3f83001813239338bc5b3895252e1fb3ea6
All our widgets support it with a constant true.
MozReview-Commit-ID: JMEItUsxYWq
--HG--
extra : rebase_source : a2661dce1ac191fdf098e631cd7878f0215643d5
Rework system font lookup under OSX so that the style system passes around the same "meta" name used by Webkit, -apple-system. This makes it so that the hidden system fonts used aren't exposed to authors. It also allows us to handle the two optical sizes of font families used under OSX 10.11, which uses San Francisco as the new UI font, with one family for text sizes and another for larger, display sizes. The patch here:
- moves system font lookup into gfxMacPlatformFontList
- assigns the font family name to "-apple-system"
- derives FindFamily to take a gfxFontStyle parameter to allow size-based lookups
- maintains a list of hidden system font families (not exposed to authors)
- maintains a mapping from -apple-system to the underlying hidden font families
The old code was just flat-out wrong. The IPDL for getting the LookAndFeel
cache from the parent during child process initialization was passing an
array it wanted to be populated as an argument, rather than using a return
value.
--HG--
extra : commitid : 2baQu56XHdn
extra : rebase_source : 7c45ecafa2ef6adb05bc753e87e354b136030958
extra : amend_source : 7b72c17d964e8b60c7c75a09ae38a28f60985583
Emilio Cobos Álvarez
Boris Chiou
Sylvestre Ledru
Stephen A Pohl
Tim Nguyen
Tooru Fujisawa
Hiroyuki Ikezoe
Jonathan Kew
Andi-Bogdan Postelnicu
Jonathan Watt
Sebastian Hengst
Tristan Bourvon
Markus Stange
Margareta Eliza Balazs
Brad Werth
stefanh@inbox.com
Neil Deakin
Thomas Wisniewski
Brandon Cheng
Phil Ringnalda
Mike Taylor
John Daggett
Nick Robson
Carsten "Tomcat" Book
Mike Conley
Juan Gomez
Ryan VanderMeulen