https://sqlite.org/fiddle/ Loads and looks file, I can edit, but none of the buttons at the top (Run, Clear, etc…) seem to click, I.e when I do press them, nothing happens. Options at the bottom do behave fine.

That’s on iPad on latest iOS. So, not supported? That would be a bummer…

PS: on touch devices the buttons could be a little bigger and more fat-finger friendly. PPS: fiddle on iPad is about accessibility for me right now. I’m lying down because of back issues, yet would like to use my favorite db for experimentations.

I tried /fiddle on an iPhone, and it didn't work. The page loads and initialises Fiddle correctly, but commands don't run.

I tried the same thing in Safari on a Mac and got the same problem. A simple way to demonstrate a problem is to try to use the 'examples' popup at the top of the page. Using Safari on an M1 MacBook Pro, the 'examples' popup doesn't pop up: clicking it does nothing. Using FireFox on the same computer, it works.

Safari on a Mac and Safari on iOS share a lot of code. I suspect that fixing it on one will fix it on another. Just to confuse things, if you're using an up-to-date iPad, you're actually using iPadOS. But that too shares a lot of code with iOS.

That’s on iPad on latest iOS. So, not supported?

Fiddle, being WASM-based, only works in "really new" browsers with the latest features (with a very vague definition of "new" and noting that "new" does not always mean "has the latest features"). Every attempt is made to keep it as compatible as widely-possible by comparing feature availability using the MDN¹ and caniuse.com² sites, but the APIs related to that whole area of web development are relatively new and not yet propagated through all browsers. A significant percentage of folks (an estimated 10-ish%, based on estimations from caniuse.com) simply won't be able to use it.

Mobile devices, in particular, are difficult to debug when they "don't work" because we don't have access to information more actionable than "it doesn't work." On desktop browsers we have access to the development tools, so can see exactly what the browser is complaining about. Debugging on mobile devices requires much more effort than is justifiable for this particular app, and is downright impossible when it's on a platform (like yours) which the developer³ doesn't have access to.

That would be a bummer…

Patches to make it work on platforms unavailable for development would be thoughtfully considered.

PS: on touch devices the buttons could be a little bigger and more fat-finger friendly.

Fiddle has not, to date, undergone any optimization whatsoever for mobile devices because, quite frankly, it's horribly uncomfortable to enter SQL on a touchscreen (regardless of finger width or screen size). Though it does get tested for basic functionality on a 10-inch tablet, ensuring that it's easy to use on a mobile device, in particular one with a phone-sized screen, is admittedly not currently a development priority.

Edit: corrected "icanuse" to "caniuse".

1. ^{^} Noting that MDN is hosted by Mozilla but is not browser-specific. i have it on good authority, from a Google browser developer, that MDN is to considered the canonical site for JS docs across all browsers.
2. ^{^} caniuse.com provides metrics of which browsers support which features and what percentage of online users use those browsers.
3. ^{^} That's currently me.

So it's a WebAssembly thing. Okay.

Someone who understands WebAssembly might read these:

https://webkit.org/blog/7691/webassembly/

https://developer.apple.com/forums/thread/650317

There are lots of enabling things I don't understand. I have Developer Tools enabled on my copy of Safari but I don't know what to do with it.

Just to add more data to this situation. I'm running a newish M1 (Monterey 12.5) and Safari Version 15.6 (17613.3.9.1.5). None of the links at the top seem to work but the ones at the bottom do work.

However in Firefox 102.0.1 (64-bit) everything seems to work. I was able to u/l a local db file and execute commands. Reset it and uploaded a different db. All seems to work.

OP here. If I’m on desktop, I don’t need fiddle to test things out, I just download the official tools.
So if only desktop browsers are supported, that’s too bad.

It’s precisely when I’m not on desktop, i.e. on an iOS tablet, that fiddle is necessary to (exec) SQLite.
There are non-local services of course, but those execute remotely, that’s not the same thing.

I get that this is OSS. Oh well, I reported my experience, and use-case. If that’s off limits to the project goals, too bad for me.

It's not off-limits, it's just using a very new technology and your browser seems to not support it all yet.

In stead of the negativity, it seems fixing your niggle is as easy as using a better browser, like Firefox. Less back-pain paradise is one install-click away.

Perhaps you are unaware there aren’t alternative browser engines on iOS? It’s always safari underneath…

Quite right, I was wholly unaware of that.

There's a few great browsers out there, it seems weird one platform foregoes them all. Is it just browsers, or does it have lock-in for other things too?
Perhaps it's time for a better device then?

Android is the same - all browsers are Chrome under the covers.

From memory it's a security thing, given how porous browsers can be.

That's just not true, I'm using Firefox (and all manner of Chrome-based browsers) on all my Android devices, Linux and Windows systems (I have to because we develop and thus test for all those platforms and browsers) - and while I don't have the MacOS test bench at hand right now, I'm pretty sure we have Firefox and some Chromes running on it too.

Also, since I confirmed the above to be sure I'm not spouting nonsense, I ran into this little nugget too: www.mozilla.org/en-US/firefox/browsers/mobile/ios/
Does not that mean it really is available for iOS also?

Saw Firefox pointed out as an exception elsewhere in the thread, so TIL.

That's not true with regards to Firefox (as you noted), but it does definitely hold for iOS, which is sad.

The question is now, how tied is the webassembly to the rendering engine (I presume tightly), wonder if SQlite-fiddle fails to run on Firefox on iOS, or perhaps by some luck will work. Anyone able to test?

The question is now, how tied is the webassembly to the rendering engine (I presume tightly), wonder if SQlite-fiddle fails to run on Firefox on iOS, or perhaps by some luck will work.

There are a combination of factors:

1. WebAssembly itself is less the issue. AFAIK the core WASM support in all of the major browsers is functionally equivalent, differing primarily in runtime speed (cough Chromeisfastest cough). In the past 3-ish months of working heavily with WASM i've yet to run across a single browser/runtime-level compatibility issue at that level of the constellation. WASM's relative simplicity of design and truly-bare-bones feature set help ensure that the numerous implementations aren't littered with incompatibilities. Both of those aspects of WASM are in strong contrast to...

2. The more likely issue for Safari mobile is the various JS APIs used by fiddle. WASM was designed to scripted by JS, so browser-side WASM apps are, as a rule, JS-heavy. WASM itself is highly sandboxed and has no access to browser-side resources like the DOM, so those can only be provided via JS scripting. In the case of fiddle, a great deal of that JS glue is transparently injected by the Emscripten framework (a dependency we're eager to get out from under but currently cannot). Even if our own code is Safari-friendly (which we don't know to be 100% true), proving that Emscripten is also doing all the right things to please it is difficult. Mobile browsers, which don't have built-in dev tools, are particularly problematic to trace down issues in.

Though every effort is made to remain as widely compatible as feasible, the compatibility-related choices are, when it comes to browsers on commercial OSes, based solely on the relevant standards documents, compatibility charts on the MDN site, and caniuse.com documentation. All development and testing so far is done on Chrome, Chromium, and Firefox on Linux platforms. No effort, beyond occasional basic sanity tests on my own tablet, has yet been made to ensure that it works on mobile devices. Phones are, frankly, the absolute last target on the priority list because entering even the most basic SQL on touchscreens is downright painful. Until/unless the app gains some form of input persistence and input history navigation, mobile devices will be a huge pain point for fiddle.

That said: there are no immediate plans to focus development on mobile platforms. Perhaps they will get some focus as priorities allow, but that's not a guaranty. Fiddle is a proof of concept and a stepping stone towards related efforts, and is not currently a first-class citizen as a project deliverable.

Then perhaps you should slap an explicit and clearly visible beta label on it, at least when loading it on any Safari based browser, given my and others testing as reported here.

Then perhaps you should slap an explicit and clearly visible beta label on it, at least when loading it on any Safari based browser, given my and others testing as reported here.

1. Part of writing portable code is not doing any sort of browser brand/version detection. We code to the docs and browsers which do the same will work.
2. Since we cannot possibly know all of the browsers it won't work 100% correctly in, such probing and warning would be futile.
3. There is a generic warning label about it being beta and unsupported which probably doesn't show up on yohr browser.

Thank you very much Stephen for taking the time to explain this and the trouble faced.

Information like this is very valuable and appreciated for our own WASM journey (which just started recently, as must be obvious).

Perhaps it would be wise to put up a "Beta" or "Concept" badge as Anon suggested, but I have less strong feelings about it. Keep up the good work!

Also, there could maybe be a link or two that explains how to report issues? How to contribute? What's expected to work where? etc...

Is there a Fiddle-specific project page somewhere with all the info? If yes, then a link to it would suffice from http://sqlite.org/fiddle.

I don't even know where the source code is supposed to be, at this point.

So far, it seems mostly a one-man project, but still featured on the main http://sqlite.org, which is iOS friendly, unlike Fiddle itself ATM.

Stephan also mentions plans for Fiddle. Can we read about those somewhere? I think deeper insights into Fiddle would be welcome, with guidelines on where to discuss too. Is this forum the right place, for example?

Also, there could maybe be a link or two that explains how to report issues? How to contribute? What's expected to work where? etc...

Like the rest of the project, its ostensible support channel is this forum. For so long as it's explicitly an unsupported experiment, however, it's unlikely to get a "find support here..." link, as that would send an ambiguous message.

So far, it seems mostly a one-man project, but still featured on the main http://sqlite.org, which is iOS friendly, unlike Fiddle itself ATM.

That's a pineapples-to-olives comparison. The whole sqlite3 site is static HTML with a minuscule amount of JS code for collapsing and expanding certain views. There's nothing there which any browser built in the past 15 years should have any issues with. Fiddle, on the other hand, is web application build on "next generation" technologies, not all of which are yet standardized. It's most definitely not unexpected that that gives some browsers bellyaches.

Stephan also mentions plans for Fiddle. Can we read about those somewhere?

There is nothing written and there are no new significant features planned for it beyond some sort of input history navigation. Fiddle is not intended to replace full-fledged desktop db apps like SQLite Browser. Fiddle was initially conceived as a proof of concept for the feasibility of supporting official WASM builds of sqlite. Once fiddle taught us a bit about how WASM works, some of what can and cannot be done with it, and the toolchains involved, focus shifted to the next steps: creating official WASM builds and higher-level JS APIs. That work is ongoing and will be made public "soon." Some of it is already available, in alpha/proof-of-concept form, alongside the fiddle source code.

"The plan" is to one day go back and reimplement, or at least improve, fiddle based on what we've learned about WASM since fiddle's initial deployment, but that is months away, at the very earliest.

I think deeper insights into Fiddle would be welcome, with guidelines on where to discuss too. Is this forum the right place, for example?

This forum is right place to discuss both fiddle and (eventually) its related upcoming WASM/JS components.

There are no deep insights to be had about it :). It attempts to be a wrapper around the sqlite3 CLI shell, the most significant difference being that the flow of input from the user is necessarily "reversed" from the CLI shell because of fundamental input-and-submit differences between a CLI app and a web app. The different UI style is a side effect of the development cost of emulating the shell's native UI in the web: the available toolkits to do so are (A) not public domain (so cannot be added to this source tree) and (B) each add large dependencies on 3rd-party code (which is simply antithetical to this project's conventions). There are no current plans to reimplement such toolkits in order to be able to mimic the shell's look and feel on the web but i'm happy to guide someone in what would be needed to create a fork which does. We have example code in place to use the jQuery.terminal plugin for that purpose, but it requires including jQuery and that plugin in the HTML file.

Unless I'm misunderstanding you, this is wrong.
Most browsers are based on Chrome/Chromium, but FireFox (and presumably various FOSS browsers) is not. FireFox is still based on Mozilla's own rendering engine, even on Android.

And just off the top of my head, since it's Android, even if all browser apps were forced to be based on Chrome, you could still do something like install Termux, install a linux distribution on that, and then run any browser under linux. Not great, but would still at least be an option.

Thanks - I wasn't aware Firefox maintained their own. Most of the other browsers that have popped up and I've reviewed using over the years did not so I thought it was mandated like iOS.

This is not a WASM relate issue, it's a html compatible issue that affect all WebKit based browser.

The original issue is just the Run button is not clickable.

I can make the Run button clickable immediately by just disable the CSS attribute .zone-wrapper - display: flex in Safari's Web Inspector.

I'm sure you can find a way to make the button clickable without affect your existing features. It's a simple task.

In addition, for what you're mentioning, "Mobile devices, in particular, are difficult to debug when they "don't work" because we don't have access to information more actionable than "it doesn't work.""

No, to debug web app in iOS Safari, it's as easy as debug it on a desktop, just search "debug iOS safari" on Google, there're 1,180,000 results returned.

Perhaps Stephan might consider the advise from https://apple.stackexchange.com/questions/273185/testing-a-website-using-safari-on-linux, to test Safari itseft (via a VM), or a Safari-like browser, on Linux. FWIW.

The above is right most of the time. If a website works in Safari on a Mac, it'll probably work in Mobile Safari running on Apple devices. There are exceptions to this, but they are complicated and most of them are related to measures the browsers take to defeat hacking attempts, and I don't see /fiddle as triggering any of them.

I can also verify that /fiddle doesn't work in Safari on my own Macs, but does work on FireFox running on the same computers.

So there's probably no need to get an iPad or iPhone to test on.

I'm sure you can find a way to make the button clickable without affect your existing features. It's a simple task.

There's a reason the run button gets disabled when it does (and isn't disabled when it needn't be). If it's possible for a user to submit SQL twice concurrently, it will eventually corrupt the shell's state and cause it to seriously misbehave, exactly as if a user somehow managed to force the CLI shell to pause one query in mid-step, start another, then resume the original.

Perhaps Stephan might consider the advise from ..., to test Safari itseft (via a VM),

For reasons which are both off-topic and inappropriate here, that would have to be done by someone else.

To stress again, here's the header which gets output at the top of the fiddle output:

This experimental app is provided in the hope that it may prove interesting or useful but is not an officially supported deliverable of the sqlite project. It is subject to any number of changes or outright removal at any time.

As other priorities allow for it, fiddle is likely to be "fleshed out" and may even get tested and/or hacked on by someone who uses the failing platform. That is unlikely for the near-term, though, due to conflicting priorities on both my part and the sqlite project's.

That said: it's not "my" code - anyone is welcome to copy it and hack on it. Browser-specific fixes posted to the forum (or, if you prefer, directly to me) will be very seriously considered. Though project licensing prohibits copying patches as-is, they can studied in order to find functionally equivalent reimplementations.