Extension goes into infinite loop when switching system dark/light mode

[janlarres]

Description

When setting the "Dark/Light mode" to "By system preference" and toggling the mode in the system the extension seems to go into some kind of infinite loop. The toolbar icon and manager page start rapidly flashing between the two modes and use up a lot of CPU. Manually setting dark or light mode in the extension, or activating the extension during either system mode, does not cause this behaviour. This only started relatively recently.

I've created a Firefox profiler result here: https://share.firefox.dev/3Flhkgn

I'm not seeing any errors in the console that look relevant.

System Information

• OS: Linux
• Browser: Firefox 136.0
• Stylus Version: 2.3.13

[tophf]

I can't reproduce the problem, so I guess it depends on something specific like which tabs are opened.

[janlarres]

Okay, this is a bit weird. I did some more experimenting and discovered that this only happens if, in addition to the above "system" settings, an individual style has to explicitly set its "Dark/Light mode preference" to something other than "None". I disabled all of my styles instead of a trivial one and set its preference to "Dark", and the flashing immediately started happening. But I haven't been able to reproduce this with a fresh browser profile yet. I'll keep digging.

[janlarres]

Hmm, I have been able to reproduce it with a fresh profile to a certain degree with these steps:

1. Open this website: https://www.mobileread.com/
2. Install this style: https://userstyles.world/style/13484/mobileread-com-dark
3. Manually set that style's preference to "Dark"
4. Toggle the system dark mode

This causes the style manager page to flash a few times, but not infinitely like in my other profile.

[tophf]

I still can't reproduce the problem, so I guess I'll just add a delay...

[Rhys-T]

Another repro on a fresh Firefox profile, on either macOS or Linux[^termux]:

• Install Stylus.
• Install the Catppuccin GitHub userstyle ('install' badge below the logo - I missed it at first).
• Set the style to only apply when the browser is in dark mode.
• Switch the browser between dark and light mode (just use Firefox prefs - no need to change the whole system).
• Stylus will loop in one theme, but go back to normal in the other.

Weirdly, when I tested this on macOS, it went nuts in dark mode, but on Linux, it was light mode that had the problem.

Anything I can do to help track this down?

[^termux]: Although it wasn't exactly a 'normal' Linux system - I'm actually running the desktop version of Firefox on Android, inside Termux.

[pyinto]

Same issue, consistently bugs Firefox when MacOS appearance toggled, rendering Firefox unusable until restarted.

[TheV360]

For me, this rapid switching only happens when Stylus' toolbar button's menu is open. It then rapidly switches between light and dark theme until I dismiss the menu. This doesn't start happening on the page that uses the "only apply when..." option nor the style manager alone. The rapid switching doesn't affect the page, either -- it's entirely contained to Stylus' UI.

Show/Hide Video of Rapid Flashing

https://github.com/user-attachments/assets/a508c166-c7e0-4400-802d-b0752cc10b4b

Edit: realized it's probably good to give some idea of my environment after someone else did, so:

I'm running Firefox 137 in GNOME 48 on openSUSE Tumbleweed, and I'm using several extensions alongside a chrome/userChrome.css. I don't see how the extensions nor browser styles would affect Stylus, as they only adjust the layout to accommodate vertical tabs with Sidebery. I also have a chrome/userStyles.css which only adjusts the monospace font in the devtools. I use a GNOME extension to automatically switch Firefox's theme with the GNOME theme switcher. These are all complicating factors in making a minimal reproduction of the bug, but I'll try my best to disable them and investigate further when I have more time.

[Baerbeisser]

I accidentally posted this on the nodejs stylus git, but since this isn't yet resolved, i just paste it here.

To reproduce:

Force Firefox to change Light/Dark mode, though it only happens about 50% of cases. It stops if you change mode again or disable and then enable the Addon again.

I do have a 00-defaults style which sets some :root variables via @media prefers-color-scheme and some site fixes using them. Maybe this interferes somehow with the addon?

Current behavior:

If you change Dark/Light mode of Firefox, the icon and UI of the addon switches periodically (ca. all 1 seconds) between Light/Dark version. But only this Addon, other addons or Firefox UI/webpages don't show that behavior. Neither a global dark style used via that addon.

No error messages in about:debugging console.

Expected behavior:

Not doing that.

Environment information:

Firefox on Linux, switch between modes via a custom script modifying gsettings org.gnome.desktop.interface and via kvantummanager for Qt apps. But i don't think that matters here.

• stylus version: 2.3.14

00-defaults.txt

00-darkmode.txt

Edit: wtf, Github doesn't allow attachment of plain-text source code files, solely based on file extension?

[eight04]

I can reproduce on Windows 10 + Firefox Nightly 140 + Stylus 2.3.14

It seems that there is a caller keeps calling getSectionsByUrl with the opposite dark value.

1. I think getSectionsByUrl shouldn't modify color scheme setting, which is a side effect: https://github.com/openstyles/stylus/blob/f3250f58685dd1348b8e3750491965bc84b56d77/src/background/style-manager/index.js#L172-L173
2. apply.js seems to report a cached dark mode status: https://github.com/openstyles/stylus/blob/f3250f58685dd1348b8e3750491965bc84b56d77/src/content/apply.js#L118 I guess this value is outdated in certain (inactive?) tabs.

Currently I have no dev environment so I just guess from the trace.

[tophf]

The proper solution is to apply the state only to the document (tab/frame), but it requires 1) slightly rewriting the cache to include the state and 2) instead of using the last known state for instant inject mode which is prepared before we can know the document's state we should probably send all the matching styles and let the document decide which one to apply in the injector.

[tophf]

apply.js seems to report a cached dark mode status

No, it caches the instance of MediaQuery, not the state.

[jcgl17]

Hi, I'm just a regular user who's had this extension disabled for some weeks, since this issue started affecting me. Is there any fix planned?

I gather from this thread that there's been some diagnosis, but am wondering if there's any (planned) work that wasn't captured by this issue.

[myfonj]

I can confirm this issue - I run into this about twice a day when I flip system colour scheme (on "dusk" and "dawn"). It does not halt anything really, but the CPU consumption is quite significant, and toolbar button's icon strobe flashing is super annoying.

Workaround

Luckily, disable-enable Stylus fixes it for me (I am on Firefox):

• either via RMB at the Stylus toolbar icon → Manage Extension,
• or Ctrl+Shift+A (= about:addons) → locate Stylus,
• switch off, then switch on.

Interestingly disabling Stylus keeps enabled styles applied (what is a good thing for this use-case), and re-enabled Stylus re-adopts them again (they can be un-applied normally etc.)

Still it would be nice to have this fixed and save this little ceremony :]

[jcgl17]

When do releases get pushed to addons.mozilla.org?

[tophf]

Probably a week, it depends on Mozilla's reviewers.

[myfonj]

It seems that the review process takes more time than usual this time :| (AMO https://addons.mozilla.org/firefox/addon/styl-us/ still shows "Version 2.3.14, Last updated 5 months ago (10 Mar 2025)"

Note: if you are on Developer's edition (or Nightly or ESR), you can turn xpinstall.signatures.required in about:config to off, download the zip for Firefox from https://github.com/openstyles/stylus/releases and then on about:addons do ⚙ (Tools) > Install Add-on from File… > pick the downloaded zip. (Tried that, seems to work OK.) Info: https://extensionworkshop.com/documentation/publish/signing-and-distribution-overview/#signing-your-addons:~:text=Unsigned,config%2e

Update 2025-08-20: AMO now provides 2.3.16 🥳