Non-working or unreliable styles auto-update

[Desynci]

Greetings,

I own a style with a large number of users, and based on their feedback, I noticed that auto-updates of style just don't work — at least for the part of them.

According to the default Stylus settings, updates are checked automatically every 24 hours, but I've seen at least three people who haven't received any updates for months (this is noticeable from version of the style, which is significantly ahead of theirs).

[!NOTE] The date of the style installation is not important — some have had style for at least several months, and some for a few days. At the same time, users said that the manual update works reliably and always installs the latest server version of the style. I also asked some of them and they replied that they had not edited the style code in any way (which cancels auto-updates).

---

Link to the style (for yougame.biz): https://userstyles.world/style/17298 As you can see, the number of weekly updates in the statistics is also very low compared to the total and weekly number of installations (I often release updates several times a day, so it should be much more).

Assumption

Maybe it has something to do with the unusual @ version attribute? I mean, it looks like vX.XX.X But that would be strange, because at the same time, manually updating the style is working fine.

[tophf]

The version looks fine. Maybe the users have disabled the auto-update by accident?

they can verify it in the editor:

[tophf]

Another thing to verify is the schedule. Open devtools console in any Stylus page like the manager and run the following:

((await chrome.alarms.get('scheduledUpdate'))?.scheduledTime - Date.now())/3600e3

It should show the number of hours until the next auto-update check e.g. 7.9429952777777775

[Desynci]

Another thing to verify is the schedule. Open devtools console in any Stylus page like the manager and run the following:

((await chrome.alarms.get('scheduledUpdate'))?.scheduledTime - Date.now())/3600e3 It should show the number of hours until the next auto-update check e.g. 7.9429952777777775

I guess we just found a reason :D scheduledTime value is always reset when the browser is closed, and sometimes it resets even if you don't close the browser. More than that, judging by the output value, it doesn't even start updating until you open any Stylus page.

The results of my tests were consistent, and if you confirm them, it might be worth switching to update-check every time the Stylus is launched, or synchronizing the time of the next update of styles with the server.

[!NOTE] My system information, if you need it:

• OS: Win11
• Browser: Yandex Browser (based on Chromium, but I can't find exact version - may be 134.0 as user-agent says).
• User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 YaBrowser/25.4.0.0 Safari/537.36
• Stylus: 2.3.14

[Desynci]

One guy showed me that he has an update-check enabled, but still hasn't received new versions for months. His result with the command was 23.353590555555556. He also confirmed that this value resets after closing the browser.

[tophf]

I can't reproduce it here, my timer is preserved after restarting the browser. Sounds similar to CCleaner deleting the data...

[Desynci]

I can't reproduce it here, my timer is preserved after restarting the browser. Sounds similar to CCleaner deleting the data...

What we could do? I guess it's clear that the problem exists and could be experienced by a large number of users, which may also reflect the statistics of weekly updates. I guess it needs fixing anyway.

I should add that I have automatic deletion of data when closing the browser function disabled.

Also, your value is saved when you close the browser — but perhaps its background services are still running in the background? I also wonder if it persists when the device is fully rebooted, because otherwise, it will need to be turned on for 24 hours to trigger the update check.

[Desynci]

@tophf, sorry to intrude, but do you have any progress on investigating this issue? Maybe there is anything I can help you with?

[Desynci]

Update: i'm not much into JS coding, but I looked at the API of chrome.alarms and I think I found an explanation for this problem.

[!NOTE] Alarms continue to run while a device is sleeping. However, an alarm will not wake up a device. When the device wakes up, any missed alarms will fire. Repeating alarms will fire at most once and then be rescheduled using the specified period starting from when the device wakes, not taking into account any time that has already elapsed since the alarm was originally set to run.

The API clearly states that alarms should persist when the browser is closed, but it's not guaranteed. Chrome recommends saving the current value to the storage and checking it on launch.

[!IMPORTANT] Alarms generally persist until an extension is updated. However, this is not guaranteed, and alarms may be cleared when the browser is restarted. Consequently, consider setting a value in storage when an alarm is created, and then ensure it exists each time your service worker starts up. For example:

const STORAGE_KEY = "user-preference-alarm-enabled";

async function checkAlarmState() {
 const { alarmEnabled } = await chrome.storage.get(STORAGE_KEY);

 if (alarmEnabled) {
   const alarm = await chrome.alarms.get("my-alarm");

   if (!alarm) {
     await chrome.alarms.create({ periodInMinutes: 1 });
   }
 }
}

checkAlarmState();

The responsible shedule function: https://github.com/openstyles/stylus/blob/ae874f577f1ac78ac70f348a94c9d3c4ad8d58aa/src/background/update-manager.js#L278-L288

As I understand it, we get this value on launch from the storage at line 55, but the problem is that it's never never being stored => so instead we just always get `Date.now()'.

Also we have similar one in sync-manager.js that probably requires fix too: https://github.com/openstyles/stylus/blob/ae874f577f1ac78ac70f348a94c9d3c4ad8d58aa/src/background/sync-manager.js#L288-L312

@tophf

[pabli24]

I noticed that the lastUpdateTime is not added to the storage.local until you manually click "Check all styles for updates". After that the timer doesn't reset when you reopen the browser.

[Desynci]

I noticed that the lastUpdateTime is not added to the storage.local until you manually click "Check all styles for updates". After that the timer doesn't reset when you reopen the browser.

Yeah, I just updated my previous answer with more info on this. It seems that value is correctly extracted from the storage at startup, but it is never written to it in any update-manager.js function. Anyway, I hope that this problem will be considered in more detail.

[pabli24]

Also the console command gives an error in the manifest v2 version stylus-mv2-2.3.14-ae874f5

[tophf]

Stylus reads the value from storage on startup and writes it to storage in resetInterval() called from checkAllStyles() called by the auto-update from onAlarm(), which is scheduled on startup as well.

but it is never written to it in any update-manager.js function

Indeed, the bug occurs in MV3 because it unloads the background script by default (I change this setting manually to -1 which is why I couldn't reproduce the problem) so every time it restarts it slides lastUpdateTime to the current moment in case the user never invoked the mass auto-update manually.

[tophf]

error in the manifest v2

MV2 should use browser instead of chrome

[tophf]

similar one in sync-manager.js

Nah, it's using a hard-coded interval of 30 minutes.

[Desynci]

Stylus reads the value from storage on startup and writes it to storage in resetInterval() called from checkAllStyles() called by the auto-update from onAlarm(), which is scheduled on startup as well.

but it is never written to it in any update-manager.js function

Indeed, the bug occurs in MV3 because it unloads the background script by default (I change this setting manually to -1 which is why I couldn't reproduce the problem) so every time it restarts it slides lastUpdateTime to the current moment in case the user never invoked the mass auto-update manually.

I don't think my reply is really necessary since you've resolved this issue, but doesn't that function literally reset lastUpdateTime to the current data? I mean, in any other case it wouldn't save the value to the storage, would it?

https://github.com/openstyles/stylus/blob/ae874f577f1ac78ac70f348a94c9d3c4ad8d58aa/src/background/update-manager.js#L297-L300 Also thank you for fixing this.

[tophf]

chromeLocal.set is writing to the storage.

[Desynci]

@tophf, Firefox v141 has the same issue, please look into it.

[!NOTE] UPD: I checked, and it turned out that for some reason, on addons.mozilla.org there's still previous version (2.3.14) of Stylus without this fix, so that's probably the reason.

The problem is the same: automatic style updates don't work. I also used the following command to check, which showed that the timer resets after each browser close:

((await browser.alarms.get('scheduledUpdate'))?.scheduledTime - Date.now())/3600e3

[tophf]

The version of Firefox doesn't matter in this case. The fixed version of Stylus is still in the review on AMO. @Mottie, PTAL...

[Mottie]

Hmmm, I didn't check on AMO after submission. Sorry. They rejected the submission

Sources, specifically Build not matching: Reproducing the submitted release version based on the provided source code package and instructions completed but the generated build is different than the uploaded xpi.

We'll probably have to push the next version.

[tophf]

@Mottie, it's unclear why. There should be a log attached with the their build attempt, can you find it? Also make sure you have email notifications from AMO.

[Mottie]

I emailed you the logs