Add check update feature

[Merci-chao]

Since the script loader typically requires updates only when it fails, I propose adding a check-for-update feature to improve reliability.

For reference, I have implemented logic in my scripts that compares the local version information with the remote file available in the repository:
https://github.com/Merci-chao/userChrome.js/blob/fc941b9235939c6b08d1719e48c2fb41804d40f3/PageTitle%40Merci.chao.uc.js#L43-L90

[MrOtherGuy]

If I read your script correctly, it compares the script version specified in the script header - but the loader script doesn't have any such header.

I suppose I could add that to the loader, or use file version information from git or something - but the larger issue here is that I don't really want to make the loader request anything over network - if individual scripts wish to do so then that's their call.

[Merci-chao]

If I read your script correctly, it compares the script version specified in the script header - but the loader script doesn't have any such header.

This is just an example, the identifier doesn’t need to be inside a header-like thing. It’s fine as long as it can check whether an update is available there.

I suppose I could add that to the loader, or use file version information from git or something - but the larger issue here is that I don't really want to make the loader request anything over network - if individual scripts wish to do so then that's their call.

Reading external things from the internet does sound suspicious, but it could be frustrating for users when the scripts they rely on suddenly fail after a Firefox update. In the worst case, the loader doesn’t fail completely and users don’t realize the problem comes from the loader, or they might even forget where to find the new version of the loader years later.

I think it’s fine as long as there’s a setting to turn the checking on or off, for users who don’t want it.

I and onemen are discussing the implementation of the update checking for the Firefox Script, and here’s a sample of the notification UI: onemen/TabMixPlus#495 (comment)

[MrOtherGuy]

Reading external things from the internet does sound suspicious, but it could be frustrating for users when the scripts they rely on suddenly fail after a Firefox update. In the worst case, the loader doesn’t fail completely and users don’t realize the problem comes from the loader, or they might even forget where to find the new version of the loader years later.

Thing is, if loader gets broken, then there is a high chance that it cannot check the updates either - thus you would likely still need to do it manually.

I didn't fully read the discussion you linked and I'm not familiar how TMP is set up, but as for fx-autoconfig I would definitely not want to update the initial config.js in program directory which then loads the loader module from profile folder - even if I could, which typically isn't the case because user shouldn't have write privileges to that folder. The config.js in my mind is supposed to be super simple and if that breaks somehow, then so be it.

Another complication here is that the versioning doesn't concern only boot.sys.mjs - it's all the files in the utils folder - they all need to be using compatible versions. This is why when any one of those changes, I bump the loader version up.

Nonetheless, maybe there is something to do here, even if I don't - at least not yet - check for new version.
Currently the loader script doesn't expose any other information about itself except for the version. With relatively small changes I can make it expose a similar blob of data that scripts can get about themselves. When done like that, I would add a "script header" to the loader script which can then be parsed much like a regular script.

On the remote side then, you could simply request the file from server, parse the header, and compare the version against the runtime value.

async function checkForUpdate(){
  let response = await fetch("<remote-url>");
  let text = await response.text();
  // parseStringAsScriptInfo requires a filename as a first parameter
  let remoteVersion = UC_API.Scripts.parseStringAsScriptInfo("fake-filename.txt", text).version;
  let localVersion = UC_API.Runtime.loaderInfo.version;
  return remoteVersion > localVersion
}

[Merci-chao]

Thing is, if loader gets broken, then there is a high chance that it cannot check the updates either - thus you would likely still need to do it manually.

Yes, so generally users should be notified to update before the loader breaks.

[Merci-chao]

Hello @MrOtherGuy,

Since I’m writing guidelines for install scripts as well as your script loader, I’m wondering whether the update‑checking feature has already been rolled out. If it has, I’ll recommend that new users choose your loader, because unfortunately onemen implemented the checking inside TMP rather than in the loader itself.

[MrOtherGuy]

No, not yet. I have played around with it a bit though and I think that adding an update check for the loader might be reasonable. The same checker can then also be used to check updates for user scripts using UC_API, but that isn't something the loader should do I don't think. I also don't see a good reason for the loader to be able to actually apply the update, but it can check for it and show a notification to open a link to the repository or dismiss and ignore the new version.

[Merci-chao]

Sounds great! Thanks for your effort. I’ll be looking forward to your updates.

[MrOtherGuy]

Right, so now there is an optional update check feature on 0.10.13 - though you need to enable it by setting userChromeJS.updates.update-check.enabled to true. At this time, the check is made when the browser has been idle for 10 seconds and only once per startup. Clicking the notification "Download..." button opens a tab to the github page, and clicking Dismiss makes the loader ignore the new version i.e. it won't show the notification for that version in the future.

Should you want to perform the update check yourself, you can do so for loader like this:

let update = await UC_API.Runtime.loaderInfo.checkScriptUpdate();
if(update.available){
  console.log(update) // { localVersion: "0.10.13", remoteVersion: "0.10.14", script: { info: ScriptInfo, response: FileSystemResult } };
  console.log( update.response.content() ) // prints the text of the file
}

As UC_API.Runtime.loaderInfo is just any ordinary ScriptInfo, you can do the same checking for any script you desire, for example:

let someScript = UC_API.Scripts.getScriptData()[0];
await someScript.checkScriptUpdate();
...

If the scriptInfo object does not have @downloadURL or @version then no http request is made because we can't do anything meaningful, in that case the function return { available: false, script: null, remoteVersion: null, localVersion }

Again, this simply performs a check, but doesn't apply anything - even if I wanted to, overwriting a single file is not what you want to do. The loader itself consists of several files, and the user needs to update them all at the same time or you get something potentially utterly broken. Handling that is multiple magnitudes more complicated than simply checking the version specifier in a remote file.

[MrOtherGuy]

A Hot fix (though not really a hotfix) on top of the previous patch, in 0.10.14 I added an item to the menubar scripts menu to manually check the update which should also show the notification even if you had previously ignored/dismissed a version. This check updates button works regardless of the update-check pref mentioned earlier because it's manual and deliberate action.

The 0.10.14 version also adds a new UC_API.L10n namespace which I needed for the update check localization and which might prove handy for other uses as well. But don't expect that to be stable yet.

[Merci-chao]

Great! I’ll check it later. Thanks for your effort.

[Merci-chao]

By the way, are there any texts that need to be localized? I can help if there aren’t too many.

[MrOtherGuy]

Thank you, but I don't think there are any at this time. We simply use localization from Firefox itself right now - the loader luckily doesn't contain too many strings that need to be localized. Nonetheless, the new L10n namespace could work nicely to provide localized strings if we end up needing to build our own localization files.

[Merci-chao]

I've tried the feature and it works well, but I have some suggestions:

1. It would be better to also display a message when manually checking for updates, if no update is available or if the check fails (e.g., due to a network error). At first, nothing happened and I thought something went wrong, so I opened the console to check if there was any error.

2. I suggest renaming the new item to "Check for updates now" and add another new item for toggle the userChromeJS.updates.update-check.enabled.

[MrOtherGuy]

It would be better to also display a message when manually checking for updates, if no update is available or if the check fails (e.g., due to a network error).

You are right, and I have a patch for that. I'm not sure if I want to add another item just to change the pref as I don't want to pollute the menu too much.

My intention was to have an update which would also improve the localization api, but it turned out a bit more complicated than I thought, and I didn't have time to finish things.