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)

If you check all three of the boxes in that section, it only shows one entry per card name. However, I do find it a bit of a pain to not be able to use the simple search box at the top-left, and have to check three extra boxes every time I do an Advanced Search. So like you, I am a fan of a global setting that would have these three checkboxes default to enabled. :) [for both advanced and simple searches]

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)

@David Catuhe I notice that in my post above, despite using the "Add code-block" button, when the code-block gets actually rendered in the page, there is still text-formatting done that adds spaces between the variables in the "document.body.addEventListener" line! (among others) Might be worth getting that fixed, as presumably it could cause code errors in some cases for people trying to copy-paste from code-block sections. (I went back into edit for the post, and have confirmed the code-block looks fine there -- issue only present when page is rendered for readers)

@David Catuhe I tried opening urzagatherer.app in my Android Firefox, and got the same issue as discedunt (of deck cards being unclickable/unopenable). I connected my phone to my PC and opened dev-tools, and I think I found the issue... In "deckCard.tsx", there is the "DeckCard.onClick" handler, and in it, there is this code block: ``` if (_evt.buttons !== 0) { _evt.preventDefault(); _evt.stopPropagation(); return; } ``` In desktop Firefox the above works fine, because when clicked with an actual mouse, the "buttons" field has "0" as the value. (I tested by running this in console: `$0.onclick=e=>{console.log(e); debugger;}`) In mobile Firefox however, the "buttons" field has "1" as the value, when tapped with one's finger. (again, checked by running the code above in console) I have not 100% confirmed that the above is the issue (for example, it's possible React's synthetic-event uses a different value for the "buttons" field than the native value checked with my console code), but I'm pretty sure it is the cause of the problem. (I tried adding a breakpoint to the original code to confirm the value mismatch, but for some reason, the remote Firefox dev-tools was failing to insert the breakpoint in the place I wanted.) EDIT: Here is the MDN reference page on the subject (doesn't fully explain why Chrome gives a different value than Firefox on Android, but does show how both "0" and "1" are "valid values" for a left-click): https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/buttons

There's probably a pretty straightforward fix for it possible, probably due to some css glitch in either Chrome or Firefox. The nice thing is that Firefox supports extensions (which also apply in web apps launched with it), so if the cause is discovered, a fix could be applied using an extension like Stylus or Tampermonkey/Violentmonkey. (I already am using these extensions to customize the Android web app to my liking)

I'm not the dev, but one solution: Install the "Aloha" browser, go to urzagatherer.app, then press "Add to -> Homescreen" in the menu. This will add a shortcut to an instance that opens up fullscreen (ie. without address-bar), and naturally with working deck clicks. That said, if clicking decks fails in Firefox, that does sound like an issue worth fixing/diagnosing.

Btw, if the update recently pushed (which makes the app full-screen) isn't showing up for you, you may just have to wait a day or two for it to show up, as was the case for me. (Another thing to check for is if the app-info has the "Allow full-screen" option enabled, though in my case that wasn't needed)

Great news; the update finally "applied", and the issue is resolved. :) I've updated the Google Drive folder with three new screenshots: https://drive.google.com/drive/folders/1GMUSpGpvlcx6KP2xeJwtwFN0sorNNVs6 The new version has even more free space on-screen than the original, as now the system home/back bar at the bottom "auto hides", which is fine to me. (not sure whether the back-button staying on screen is worth it or not, but I can swipe up to have it display -- and in any case, I definitely like this layout better than the one with the address-bar at the top) As seen in the last screenshot, in the advanced-options panel I can now easily press the full-text filter-box without having to make multiple tap attempts. While I do still need to switch to landscape mode for it (as opposed to a scrollable popup window with those advanced options), that's not a high priority, and the interface works fine again. Thanks for the quick solution to the issue!

Just tried that (uninstall app, then clear site-data and cache in Chrome, then install app again) and still noticed no change. Was the change made to the Android/Java code or the web app's Javascript code? If it's in the Javascript portion, I'm guessing it's probably just caching -- as the mismatched versions between browsers and the Android app I've observed at times suggests that they have caches that just take time to expire.

Okay, the update showed on the Play Store, and I did the app-update, but there was no update-message and I didn't see any changes to the address-bar or filter-options-ui. I will try again tomorrow in case it's a caching issue of some sort.

Thanks! However, I've tried uninstalling and reinstalling the UrzaGatherer app, as well as clearing the cookies, site-data, and cache of my device's default browser (Chrome), but I am not seeing a new update message or any changes to the filter-options UI. Possibly I need to wait a day or so for the cached service-worker to expire or something (as was involved in that issue I hit a couple months ago), to get the new version/code to load... Is there something I should be looking for to confirm I'm running the updated version/code?

Sure, here is a Google Drive folder with screenshots: https://drive.google.com/drive/folders/1GMUSpGpvlcx6KP2xeJwtwFN0sorNNVs6 The first three are with the address-bar; the last three are without the address-bar. As can be seen, the advanced filter-options literally run off the end of the screen (without a way to scroll) when the address-bar is present. Without the address-bar, the advanced filter-options just barely fit. (the full-text search requires tapping on that tiny sliver of the box that fits above the cutoff, but I'm able to click it after a few attempts)

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.

Yeah, I tried it with Firefox, and thankfully the issue is not present there. (see my edit, and my second comment, for further observations/details) So I think it's a bug in Chrome, that somehow is getting triggered.

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.)