Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Override change event #33

Closed
jakearchibald opened this issue Dec 6, 2023 · 5 comments
Closed

Override change event #33

jakearchibald opened this issue Dec 6, 2023 · 5 comments

Comments

@jakearchibald
Copy link

The override property currently accesses preference override data synchronously. Instead, the spec should detail how the data is synchronised between agents.

When this happens, it feels like there should be some kind of event to inform the developer that one of these values has changed.

@lukewarlow
Copy link
Collaborator

If I'm understanding correctly would something like #7 (comment) address this (the change event part at least)

@jakearchibald
Copy link
Author

Yeah, but if you introduce a computed value, you probably need two change events, one for the computed value and one for the override value.

@bramus
Copy link

bramus commented Dec 8, 2023

I built a POC browser extension that allows changing light/dark mode on a per-site basis by the click of a button. The extension taps into the Web Preferences API for this: read and override the value of navigator.preferences.colorScheme.

chrome-dark-mode-toggle--web-preferences-api.mp4

One of the features of the extension is that the icon in toolbar reflects the active state of the page: if the page is in dark mode, the icon will show a dark icon. If it’s in light mode, the icon will show a light icon.

Right now my implementation isn’t 100% accurate, as I rely on watching the prefers-color-scheme media query via window.matchMedia('(prefers-color-scheme: dark)').addEventListener('change', e => … }) which doesn’t always trigger.

My OS is in Light Mode.

  • If I override navigator.preferences.colorScheme to dark, the MQ listener triggers, so I can update the icon to dark.
  • If I then override navigator.preferences.colorScheme to light, MQ listener triggers, so I can update the icon to dark.
  • If I then clear the navigator.preferences.colorScheme, the MQ listener DOES NOT trigger because the page basically went from light (override) to light (system).

Mutatis mutandis for an OS in Dark Mode where the MQ listener won’t trigger from Dark (system) to Dark (override).

For this reason, a change listener on the PreferenceObject would be feasible, as I also expressed in https://x.com/bramus/status/1733263658543669574 before being pointed to this issue right here.


RE the two values: that’s what I basically do in my extension as well: I get the applied lightOrDark value from the MQ + I get the navigator.preferences.colorScheme.override value. By comparing both I know the lightOrDark value is set by the override or not.

lukewarlow added a commit that referenced this issue Jan 15, 2024
@bramus
Copy link

bramus commented Jan 15, 2024

Thanks for following up on this, @lukewarlow!

@lukewarlow
Copy link
Collaborator

Apologies for the delay! I've updated the spec and will update the chromium implementation soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants