For some reason, in Chrome (latest version), Urza Gatherer kept loading as v9.9.7 (or whatever the latest 9.9.X version was).
I tried:
1) Refreshing the page.
2) Opened dev-tools (with "Disable cache" on), and hard-refreshed the page. This temporarily solved it, but the issue returns as soon as I close the dev-tools and refresh.
3) Cleared all cached images/files in my browser, then redid steps 1-2.
4) Updated Chrome to the latest version, and completely restarted Chrome.
5) Cleared all local-storage and cookies of the site, then redid steps 1-2.
6) Manually went into the dev-tools -> application -> service workers panel, and tried updating the worker; no improvement.
7) Tried enabling the "Bypass for network" option. This worked while dev-tools was open with that option enabled, but the site reverted to 9.9.X when I closed dev-tools and refresh.
8) Tried "Updating" the service-worker, then "Unregistering" it, with "Disable cache" on, then pressed "Empty cache and hard refresh" on the refresh button. Again, worked temporarily, but the site reverted to 9.9.X as soon as I closed dev-tools and refreshed.
Having a background in web-development, I was getting quite annoyed with how the service worker somehow -- apparently -- kept retrieving an old version of the site and trying to run it. I eventually decided there is probably a bug deep somewhere in either Urza Gatherer or Chrome (I suspect it's a bug in Chrome, although maybe there's some developer-side workaround that could be implemented).
In the end, I did finally find a solution:
1) I installed the "Block Service Workers" extension: https://chrome.google.com/webstore/detail/block-service-workers/ceokjgeibfjfcboemhdpkdalankbmnej
2) I did an "Empty cache and hard refresh" of Urza (just to be sure). The extension popped up a message asking if it should allow the service-worker to be installed/used.
3) I said "No"; and yay, v10.0.X showed up as desired.
4) I did some more fiddling around to confirm the issue was actually fixed, including clearing the extension's blocking, trying more hard-refreshes, etc.
5) After that period of fiddling, I did some regular refreshes with the dev-tools closed, and *finally* the issue seems to be resolved. (the v9.0.X has not shown up again since then, thank goodness)
Anyway, since I didn't see any results for this issue during a search for it on these forums, my guess is that the problem is either rare, or something most people don't notice. (EDIT: Nevermind, it happened for a friend of mine as well. See my comment on Sep-28-2023 for the details, local steps to fix, and a proposed workaround that the developer can add.)
It's probably not even worth your time to investigate it. However, because of how annoying/hard-to-fix the issue was, I figured I would mention it on these forums so people in the future can find this information through search, if/when needed.
TL;DR: To fix, open dev-tools (ctrl+shift+i, or f12), go to the Application page, expand the Cache Storage entry in left-panel, then right-click each cache entry there and press "Delete".
In some cases, you can also just open the app's "Settings" panel, then click Database -> Clear local cache. (for some reason, this button only appears in some cases)
Okay, the issue happened on my desktop again. I tried deleting the "urzagatherer-v1433" cache (which was the only "urzagatherer-v..." one there), and to by surprise that didn't resolve it (since that's what fixed it on my laptop).
However, when I then deleted the last cache in "Cache Storage" (named "urzagatherer-images-v1"), the issue resolved!
And I think I know why. Take a look at this screenshot: https://i.imgur.com/tsy6dUe.png
As can be seen, ther "images-v1" cache is somehow also caching the "Urzagatherer.js" file! So there is something wrong with the caching code that is causing it to (sometimes at least) put the service-worker's code files into the "images" cache alongside the card-images, causing that stored version to "stay there forever" and block application of newer versions of the code that get published.
I can take a closer look at the code to try to find exactly where the buggy line(s) are if you want, but I'm guessing the info above will be enough for you to know what needs fixing/changing.
Okay, the bug happened on my laptop now as well.
While resolving the issue, I have found the "root cause" of at least one of the ways that the bug can occur: https://i.imgur.com/Z82LLDn.png
Apparently the Cache Storage shows two different versions of the service-worker contents, version 1339 (v11.7.4) and version 1433 (v12.5.8), existing at the same time. And while this was the case, the "older one prevailed" for some reason. (no matter how many times I refreshed it kept showing/using the old version)
To fix the issue, I tried deleting the images cache (as seen in screenshot), but that didn't help (which is odd, since deleting that cache is apparently what the "Clear local cache" button used to do, and that resolved the issue for me in the past). I then tried deleting the "v1339" cache entry, and that fixed the issue as soon as I refreshed the page.
So, there seems to be some sort of flaw in the cleanup of old entries of the service-worker contents in the Cache Storage.
Okay, apparently this issue is not specific to just my machine; a friend of mine hit the same issue. (where UrzaGatherer was stuck on a version that was around a year old) He tried the following: 1) Opening dev-tools, holding "Refresh", pressing "Hard Reload". That solved it for that one refresh, but did not permanently solve it. (ie. they need to have the dev-tools open and press hard-reload to fix it each time they want to visit the site) 2) Doing: dev-tools -> Application -> Storage -> Have only the "Cache storage" checkbox selected -> press "Clear site data" (apparently it had 945mb of cache storage used) After step 2, is when the issue was fixed for him (which matches with my own experience, fixing it several months ago). So as I suspected earlier, I think the problem is that: * Chrome has a limit on how much a website can store in its local storage and cache. * Over time, the cache fills up (presumably from card images) and ends up exceeding the limit. * Then, when UrzaGatherer tries to download the new version of the service-worker (which contains the app's code), it fails to do so, because storing the new version would increase the storage usage beyond the limit. Now, theoretically this shouldn't be the case -- because the "Application -> Storage" panel explicitly lists its "storage quota" (for me this is "1199813 MB"), and the actual usage is well below that quota. But I suspect there is some additional limit of some kind, which is being exceeded, causing service-worker downloading/updating to fail. In any case, it's a pretty serious problem, since when it fails to update the service-worker, it means any new sets are left out. And if the user does not have a technical background, they will almost certainly not be able to resolve the issue on their own. ========== Alternatively, perhaps the issue is not that a cache limit/quota is being exceeded, but rather that there is some kind of "special cache" that is used for service-workers, and it is somehow getting corrupted and unable to be updated in certain cases. Assuming this is the case, the only ways I've found to clear this "service worker cache" is either to: 1) Follow the "Step 2" at the top of this post. 2) Press the "Clear local cache" button in the UrzaGatherer settings. (this worked for me in the past) It's worth noting that simply pressing "Update" or "Unregister" for the service-worker (in dev-tools -> Application -> Service workers) does NOT fix the issue. (presumably it just keeps pulling from the "special service-worker cache" that still holds the old version) While pressing the "Clear local cache" button in settings appears to fix the issue, I've looked more recently and unfortunately it appears to have been removed; might be worth adding back. Anyway... my suggestion as a web-dev, in the absense of a "fundamental fix" for the issue, is a workaround like so: * Have some tiny additional "cache_checker.js" script file, which is loaded alongside the main codebase / service-worker, and which is never cached, to ensure that you can push changes to that cache-resolving script later if needed. (and in the case of the user running offline, it's fine for it not to load, since the service-worker could only get updated while online anyway) * The job of this extra script, is simply to check which version of the service-worker is running. (eg. indicated through a global/window-attached variable) * If the service-worker's version is not the latest, and it's been more than X days since the release of the latest version, then the caching bug has been detected; alert the user to the problem (perhaps a popup, or a banner at the top/bottom of the page), and ask if they want to attempt a fix. * The "fix" operation then consists of calling whatever function used to be attached to the "Clear local cache" button in the settings, and then refreshing the page. (since that's what fixed it for me in the past)
Okay, I think I finally fixed the core issue. (knocking on wood) What I did (after disabling the workaround extension for blocking/gating all service-workers): 1) Closed all UrzaGatherer tabs. 2) Turned off my internet. 3) Opened UrzaGatherer, went to Settings, then pressed "Clear local cache" in the database section. 4) Turned internet back on. 5) Refreshed the page. (and again, and again, and in new tab, and with dev-tools open and closed, and with hard-refresh, etc. to make sure the fix persisted)
So the key seems to be the "Clear local cache" button in the "Database" section at the bottom of settings. It's odd that that did it though, since as mentioned I already tried clearing all cache for UrzaGatherer through the dev-tools; but maybe UrzaGatherer has some kind of "cache" that is not seen by the dev-tools cache-clearing tool.
If the app's "Clear local cache" button is not supposed to have anything to do with the service-worker code (ie. app version), then my suspicion is that maybe there was something about what the app was caching that was making the app's state "invalid" or "over a quota" or something, causing the attempt to update the cached service-worker code (to the newer versions) to consistently fail. And so by pressing "Clear local cache", it restores the app's state to something that wasn't invalid/over-quota, freeing that up.
Anyway, the above is just a guess; the fix above worked for me (and without needing that service-worker-blocker extension anymore), so I am content not knowing the full details.
Update 2: I've made some additional observations: 1) When using the service-worker-blocker extension, it appears that the "OneDrive" sync provider does not work. (the console just says "Working offline" whenever I try to connect to it) 2) I then tried to reset the blocker extension, and this time clicked "Yes" when asked whether to allow the service-worker. Oddly, this seems to fix the service-worker versioning issue, even with dev-tools closed and refreshing normally. (so long as the extension is kept active)
3) With the service-worker now allowed (after passing through the extension gatekeeper), the "OneDrive" sync provider somehow was still failing! (with the same "Working offline" message)
4) However, when I switched to the "DropBox" sync provider, it was able to connect -- and I successfully pushed and pulled from my cloud storage.
5) So there is one path to fix the issue I've been hitting, when in Chrome: install the service-worker-blocker extension, then reload urza and say "yes" for allowing the service-worker, then just always use DropBox as your sync provider going forward rather than OneDrive.
😑
I spoke too soon. Somehow the "reversion to 9.9.5" is back, now that I've disabled the extension.
So the extension didn't really "fix" the issue long-term -- it apparently just blocked the issue from showing up, while active.
That said, at least there is a workaround. (keeping that extension enabled long-term, to always block Urza's service-worker from ever being used)
(Another reason I think Chrome is at least partly to blame is that this issue is not happening in Firefox for me -- at least not currently.)