Steps to replicate the issue (include links if applicable):
What happens?:
What should have happened instead?:
Other information (browser name/version, screenshots, etc.):
No, it only covers users who can set those browser- or system-wide preferences that automatic dark mode checks. This task is for users who have to override automatic detection by manually selecting the dark mode in Vector's rail.
What about editors who want to compare dark and light mode experiences side by side when fixing dark mode issues? As a volunteer editor I often do that....
I don't personally do side-by-side and find it enough to just click between the radios on the single page, but that doesn't feel like an invalid use of a "lagging" switch. (NB to my mind that definitely makes this a feature request and not a bug.)
This would need an update in mediawiki.user library
https://gerrit.wikimedia.org/g/mediawiki/core/+/3c4d177456c3a0a642f61aafd4a7562e34850a0f/resources/src/mediawiki.user.js
It would need some cross-tab sync mechanism, where a tab could trigger a change event and other tabs could subscribe to it; and than either mw.clientPrefs or the dark mode control form could trigger / subscribe to events, depending on whether we think auto-updating client preferences is always a good thing or should be done on a case-by-case basis (because e.g. other components might initialize themselves in a way that depends on the value of the preference).
There are probably quite a few use cases for a tab sync mechanism (T326042: Synchronise state of notifications between tabs and central autologin come to mind), and seems like a complex feature that could be implemented in a number of different ways. Probably should be integrated with Vue too. IMO worth a separate task and a search for potential use cases.
While this is an interesting request, it would require significant changes to the way dark mode currently functions. Declining as it's unlikely we will pick this up in the near future.
Please see mw:Bug_management/Bug_report_life_cycle / mw:Bug_management/Development_prioritization. That is not a valid reason to decline a task. It's a reason to set priority to low instead.
Once the page is loaded, other components may have made assumptions based on it. I think it would create too much risk of unstable UI, loss of place, loss of user input, incompatible features, etc if we try this generically.
However, if specific options (such as Vector dark mode) consider it desirable to broadcast this, I think that can be supported and reasoned about in a stable and predictable manner.
Thanks for weighing in Timo! Although this is an interesting idea I do think this would be undesirable both from a product and technical point of view. From a product point of view this could be particularly annoying if an editor is specifically testing dark mode in one tab and normal mode in another! This is also specifically what automatic mode (operating system mode) was made for - that will update automatically based on the user's operating system. From a technical point of view this would a lot of adding complexity.
@Krinkle this might be a good fit for a gadget if the event listener itself is low cost, but it definitely wouldn't be added to Vector or Minerva itself given @ovasileva already declined this (T396268#10954334) and from a technical point of view this seems like a big lift for little gain.
It was declined for a different reason. Thanks for clarifying that it is generally declined regardless of effort amount or who works on it.