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