Stylus randomly fails to apply styles or open the manager and options

[chocmake]

Bug Report

Bug Description

With one of my Linux installs in the last day (seems to match when Stylus was last updated) I noticed in Vivaldi browser that userstyles randomly have not applied to sites, also causing the Stylus button to not present its menu when clicked nor the userstyle manager able to be opened.

A restart of the browser resolves the issue before it randomly occurs again during some point of the open session.

System Information

• OS: Linux (Kubuntu)
• Stylus version: 2.0.8
• Browser: Vivaldi 6.9.3447.48 (Chromium 128)

[tophf]

I can't reproduce the problem, but it sounds like there's an error in the background service worker.

1. open chrome://extensions
2. enable Developer mode switch in the top right corner
3. Click Service worker in Stylus card
4. Switch to the console tab in the devtools window that opens, and copy the errors here if there are any.

If there are none, click Details button, then enable Collect errors. When an error occurs it will be shown in the extension's card in chrome://extensions page. There will be one warning that is safe to ignore: 'webRequestBlocking' requires manifest version of 2 or lower.

[chocmake]

So after testing with the dev mode and service worker + collect errors enabled I couldn't reproduce it after many hours and various browser sessions. While during the initial half day when I experienced the bug it occurred 3-4 times.

So I disabled the collect errors and dev mode, as a test to see if perhaps it affected reproducibility, and within 20 minutes the bug occurred again (currently have a tab open with an affected site). I should note that hard reloading the tab doesn't resolve the bug, nor does opening a new tab of the site.

Edit: also seasonal cheers :)

Edit 2: re-enabled dev mode/etc and opened the console before refreshing the affected site. This is the output:

Uncaught (in promise) Error: Target disconnected
    at Proxy.exec (sw.js:1:7536)
    at Proxy.<anonymous> (sw.js:1:7405)
    at refreshSystemDark (sw.js:1:32664)
    at sw.js:1:92511
    at Array.map (<anonymous>)
    at sw.js:1:92483
sw.js:1 Uncaught TypeError: Cannot read properties of null (reading 'get')
    at MessagePort.onMessage (sw.js:1:8076)
sw.js:1 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'values')
    at trackTarget (sw.js:1:8253)

[tophf]

When the page wasn't styled, did you have Stylus' style manager page open? This bug is fixed in the upcoming v2.1.0. 🎄

I couldn't reproduce the new errors you've shown, so my fix may be incomplete. Can you verify it by installing this mv3 test build as an unpacked extension? You don't have to unpack it per se, just drag'n'drop the zip file into chrome://extensions page when developer mode switch is enabled. It'll be a separate extension, so disable the main one to avoid interference.

[chocmake]

When the page wasn't styled, did you have Stylus' style manager page open?

No.

Can you verify it by installing this mv3 test build as an unpacked extension? ...

Sure. I'll report back if the error occurs again.

Do you expect having dev mode + collect errors would interfere at all with reproducibility? As it was a bit unexpected the issue not occurring only while that was enabled.

[tophf]

dev mode + collect errors would interfere

Unlikely, because it would be a bug in the browser that affects many extensions. It's more likely there's a heisenbug in Stylus.

[oddhack]

I'm seeing similar behavior in Chromium 130.0.6723.58 for Debian 12, Stylus 2.0.8. Unfortunately I made my way to the service worker errors, saw the errors, but then cleared the console and tried reloading the problem page in hope of having a clean slate, and did not see the errors popping up a second time - but the behavior of not applying styles remained the same. Perhaps I don't understand how to navigate to a demonstration URL in a way that is reflected in the dev console? I'm unclear whether that's supposed to be showing what's happening in all tabs with service workers, or just the tab the developer mode / dev console were selected from. In any event, this does seem to be consistent timing-wise with the recent update to 2.0.8.

[chocmake]

Since I didn't experience the issue on the test build (default settings, single style added) I disabled it not long before this post and enabled the regular addon which had auto updated to v2.1.0.

Within about an hour the issue occurred. So I re-enabled dev mode to check the service worker console:

sw.js:1 Uncaught (in promise) Error: Target disconnected
    at Proxy.exec (sw.js:1:7539)
    at Proxy.<anonymous> (sw.js:1:7408)
    at refreshSystemDark (sw.js:1:32697)
    at sw.js:1:92394
    at Array.map (<anonymous>)
    at sw.js:1:92366
sw.js:1 Uncaught TypeError: Cannot read properties of null (reading 'get')
    at MessagePort.onMessage (sw.js:1:8079)
sw.js:1 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'values')
    at trackTarget (sw.js:1:8256)

So seems at least still present on v2.1.0 but unsure about the test build v2.1.1.

[tophf]

Yeah, that what arguably fixed in 6bde110 after 2.1.0 was published.

[chocmake]

Ah, good to know. Will keep an eye out for the behavior of 2.1.1 stable, too, with my regular settings.

[mleyen]

The bug is still present in 2.2.0.

Uncaught (in promise) Error: Target disconnected
    at Proxy.exec (sw.js:1:7539)
    at Proxy.<anonymous> (sw.js:1:7408)
    at refreshSystemDark (sw.js:1:32537)
    at sw.js:1:92345
    at Array.map (<anonymous>)
    at sw.js:1:92317
sw.js:1 Uncaught TypeError: Cannot read properties of null (reading 'get')
    at MessagePort.onMessage (sw.js:1:8079)
sw.js:1 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'values')
    at trackTarget (sw.js:1:8268)

[tophf]

Does it occur randomly for you as well or is there a reliable way to reproduce it?

[mleyen]

No, it's random.

Disabling and re-enabling the extension fixes it without restarting the browser.

[tophf]

As a workaround try increasing cache duration:

[oddhack]

Trying to go to the Options screen to change the cache duration, or even just Reload the extension, spins forever, for me.

As a workaround try increasing cache duration:

[tophf]

@oddhack, try checking the devtools console for errors, both of the options page and that of the worker.

[oddhack]

I stopped and restarted the extension from the //extensions tab which is OK for now, but will try and check on that if it happens again.

[tophf]

Before that happens, try setting the cache option.

[chocmake]

Can confirm 2.2.0 is similarly affected. Have since configured the Advanced settings per tophf's suggestion above and will see how it fares.

I wonder if my 2.1.1 test build experience was different merely because of there only being one style added and with the default settings (though I don't actually recall changing the main settings in my stable addon prefs apart from enabling dark theme always). As the normal builds have been more frequent (with 2.1.0 stable it was occurring every like 5-10 visits to a styled site).

Edit: additional context that might be useful: I have like 100 tabs open in current browser tab groups/'workspaces', various of which are sites that have associated userstyles active in my regular Stylus profile. Perhaps since in the v2.1.1 test build I was styling only a single site (and afaict I don't have any other open tabs with that site) it wasn't being as stress tested. OTOH most tabs are hibernated when the browser gets launched so not sure they'd be actively handled by Stylus en masse.

[tophf]

Try the nightly builds.

[chocmake]

Haven't encountered the issue so far on this test build (testing with my full imported config this time) but one error has appeared in the Errors section of the extension manager:

Uncaught (in promise) TypeError: Error in invocation of tabs.sendMessage(integer tabId, any message, optional object options, optional function callback): No matching signature.

sw.js:1 (anonymous function)

(The stack trace is the entirety of sw.js)

[tophf]

Yeah, I broke tabs.sendMessage yesterday, fixed it just now.

[skeleton66]

Nightly builds will have this error.

[tophf]

Nightly builds will have this error

Which build specifically? This error can only occur when the extension files are deleted or there's a bug in the browser.

[skeleton66]

I think I installed 2.2.0 instead of 2.3.0. My apologies.

[tophf]

The numeric version doesn't change in nightly builds, only the commit hash.

[skeleton66]

Not only did I get the error above, but I also got this error and can no longer use it.
Is there a problem with the way I installed it?
I use Google Chrome on my Windows browser.

[skeleton66]

https://github.com/openstyles/stylus/actions/workflows/ci.yml
I installed this one marked 2.3.0, but if it is modified by the administrator, will it no longer work?

[tophf]

I don't know really because the list contains errors from old builds that are fixed now. Try clearing the list and then do something that causes an error, then describe it in a new issue with a description what you did.

but if it is modified by the administrator, will it no longer work?

Depends on how it was modified.

[chocmake]

Just a small observation while testing the latest test build. I'd clicked a link from a styled site, then navigated back again and the site became unstyled but I reflexively refreshed the page and it became styled again (something that wouldn't happen when the bug described in the OP would occur, ie: in prior addon version tests it would remain unstyled, though perhaps these are two different unstyled scenarios occurring).

The curious part was when clicking the Stylus addon button in the toolbar the pop-up did appear but its theme was now light, while it was dark themed previously (it's on the 'System preference' theme option).

Nothing appeared in either the service worker or offscreen.html consoles, fwiw. This was with cache/injection settings set to default again while using the test builds.

[tophf]

Should be fixed now.

[chocmake]

Swapped from the prior test build to testing this build and eventually encountered the unstyled effect.

No errors appeared in either the service worker or offscreen.html consoles ('Collect errors' was enabled) but did appear in the Error button:

Uncaught (in promise) DataError: Failed to execute 'delete' on 'IDBObjectStore': No key or key range specified.

When clicking the Stylus addon button in the toolbar the pop-up did display, with the correct dark theme but it didn't display any userstyles for the URL, despite there being a few ordinarily.

Reloading (soft or hard) the the page didn't fix the styling of the page, unlike the prior test build experience posted above. Nor did opening a new tab and entering the same site.

(Also not sure if I've mentioned it before but when when the styling doesn't appear for one site it doesn't appear for any other site as well, this has been consistent through all the tests apart from the last test build where it was resolved after a page reload but not sure that last experience was the same bug)

[tophf]

Failed to execute 'delete'

This is already fixed in the latest nightly.

[tophf]

But I don't think this error could have caused what you described, because it occurs in a separate call whose result is discarded. What you describe seems so outlandish to me that I wonder if there's a database corruption. Try uninstalling the extension completely and install it again. Don't forget to export the backup.

[chocmake]

I wonder if there's a database corruption. Try uninstalling the extension completely and install it again. Don't forget to export the backup.

So I uninstalled the disabled stable addon and the test builds (only one of which was enabled). Then installed this test build and imported my config as before.

This time within just a few page visits the same issue described in the prior post occurred, however this time all styles were missing when the style manager was opened. This is the first time seeing this behavior.

At first I thought I'd misremembered importing the settings so I imported them again and then the same thing occurred shortly following.

Does it matter which version of the addon was used to export the settings? As the export was from a few stable versions prior (within the time period of this bug report) and I've been using that since. Tested re-importing the settings then exporting from the latest test build and a diff showed only the _rev key values changed.

---

To test if it was my imported settings/styles affecting things I then uninstalled that sole test build, reinstalled it, then created just a single userstyle (simple body background color change) with no Stylus settings changed. I encountered the same issue of that style disappearing within just a few page reloads (ie: no styles in style manager).

---

Edit: could reproduce this in a separate Linux install with Vivaldi (latest v7.0.3495.27, with only a handful of tabs open). Within just a dozen page loads the sole style added disappears.

---

Edit 2: strangely in that same separate Linux and Vivaldi install the Style manager now does display the userstyle and it appears in the addon button pop-up menu but the style doesn't get applied.

No errors in the service worker or offscreen.html but the errors button shows:

Blocked attempt to show a 'beforeunload' confirmation panel for a frame that never had a user gesture since its load. https://www.chromestatus.com/feature/5082396709879808
Skipped 1 unrecoverable styles: [object Object]
Uncaught SyntaxError: Unexpected token '<'
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'drive')
Uncaught (in promise) TypeError: Cannot read properties of null (reading 'then')

GIF since it's easier to show:

[tophf]

This is just amazing.

[tophf]

Found some mistakes in the code. You have a great skill to expose weak spots.

[pabli24]

Someone on discord also complained that all his styles are gone after the chrome extension updated

[tophf]

With this specific bug, the styles are actually there, it's just that the cache is incorrectly maintained.

1. Reload the extension by right-clicking the icon.
2. In the options, set the theme to anything except System
3. In the options, set Style cache duration to -1

[Kein]

I never had this bug ever until now, Stylus completely does not work

[tophf]

Did you try the workaround I posted in the comment above?

[chocmake]

In my original Linux install tested this test build (with settings imported this time) and at some point I observed an unstyled site and the styles disappeared.

Separately installed the same test build in the other Linux and Vivaldi install (having uninstalled the prior test build) and was able to reproduce with just a single style and no settings changed, though later clicking the toolbar button again restored the userstyle in the pop-up list (and also in the style manager).

Then added the latest workaround above, for each install, but style still wasn't applied (style appeared in toolbar menu though).

Then tried:

• Disabling/re-enabling the extension a few times and still unstyled.
• Disabling/re-enabling the userstyle from the toolbar menu but still no difference.
• Hard reloading page.

What worked was disabling the active userstyle then enabling a separate userstyle for the same domain, upon which the separate userstyle took effect and then prior active one after disabling the separate one again.

However the user would have to have another userstyle for the same domain/URL for this to be feasible. For the install that only had a single userstyle I then tried adding another while the site was in the unstyled state but upon saving the new userstyle an error message popup within the editor appeared saying:

cache.maybeMatch.add is not a function

For comparison, in versions days earlier it was possible to just disable then re-enable the addon to recover from an unstyled state.

In my original install the only error was in popup.html (stack trace: popup.js):

Uncaught (in promise) TypeError: cache.maybeMatch.add is not a function

But I hadn't entered the editor for that install.

[tophf]

But this build doesn't use cache, so it just can't happen... I wonder if you can post a complete instruction for me, because I haven't been able to replicate any of these effects yet.

[tophf]

cache.maybeMatch.add is not a function

Hmm, judging by the source code this can only happen if IndexedDB is broken in the browser, which would probably explain all the magic. Maybe it's caused by some security-related setting in the browser?

[Kein]

Did you try the workaround I posted in the comment above?

No, I rolled to older version and will wait a year or so until it is stable again. I dont need 90% of new features

[tophf]

Yeah, well, it may take 10 years because these bugs just don't occur for me, so how can I fix them?

[tophf]

Scratch that, I think I found the problem.

[chocmake]

But this build doesn't use cache, so it just can't happen... I wonder if you can post a complete instruction for me, because I haven't been able to replicate any of these effects yet.

Here are a couple videos showing the full reproduction process, in my separate Vivaldi (v7.0.3495.27) install:

Part 1: test build installation and writing the first userstyle:

part-1.webm

In-between that video and the next, to trigger to the unstyled bug I just reloaded the page 1-2 dozen times along with closing and re-opening the site. Within ~2 minutes the site became unstyled.

Part 2: after the site became unstyled and trying the workaround above, along with trying to get the site styled again:

part-2.webm

In that video making a separate userstyle failed to trigger the workaround I described in my prior post. I think it requires an existing userstyle present prior to the unstyled behavior.

[tophf]

Yeah, thanks.

[tophf]

Hopefully this is fixed in the latest nightly, at least I can't reproduce this anymore.

[Freezard]

Stylus stopped working for me as well since a few days ago. I set the cache to -1 and so far it seems to work again.

EDIT: Nevermind it's still broken.

[chocmake]

Hopefully this is fixed in the latest nightly, at least I can't reproduce this anymore.

So far haven't run into any of the issues using this test build (without any workarounds added). Tentatively would say it's looking good.

[sergio9929]

This still happens to me after the last update (2.3.5). I know it happens on youtube using this userstyle: https://userstyles.world/style/538/full-width-youtube-with-optional-zoom-to-fill

[tophf]

I need an exact sequence of actions in order to fix it, assuming it's not already fixed in the latest nightly build.

[sergio9929]

seems random, but I will try to look for a pattern.

[tophf]

Sounds like another bug I've already fixed in the nightly builds.