Connecting doesn't work in Safari

[CrabNejonas]

Currently, the UI is a website that will be hosted at debug.crabnebula.dev (or similar) where it will attempt to make a connection to ws://localhost:PORT where PORT is the port that the local instrumented apps JSON-rpc server is listening on.

This works fine in Chrome and Firefox, but not in Safari (ofc sigh).
Judging by this webkit ticket it also seems like this is not going to be fixed anytime soon, even though it technically goes against the current W3C standard. It seems like the Safari team and higher management within apple treat this behaviour "as intended" likely so they can claim better security and privacy than other browsers.

In short: This situation will remain as-is for the foreseeable future.

So what do we do about it? We essentially have two options:

1. Ship a builtin SSL certificate (either for localhost:3000 or for a custom domain redirect we add like local.devtools.crabnebula.dev) add that builtin SSL certificate to the local devices keychain and then we can connect via wss:// or https://
2. Not support Safari and prompt users to install a different browser like Chrome or Firefox
3. Ship the app as Tauri-only (no web hosted version)

Option 2

This means detecting Safari and prompting people to use a different browser. I spoke with @atila-crabnebula about this and we realised we don't have any data on this. So lets do some data science aye:

This chart shows a breakdown of the @tauri-apps/cli installs by OS, taken from the downloads of each os-arch specific sub package published to npm (like this one). Here's a more detailed breakdown that also includes breaks this down by arch and variant:

Now, this data is probably skewed by all sorts of factors:

• As @tauri-apps/cli is commonly used in CI, the large market share of linux can be explained by the many installs in GH action runners.
• There are many other ways to install the Tauri CLI it's not clear whether macOS users have different preferences regarding npm, cargo, etc.
• Npm seems to have some issues with download numbers recently, anecdotally reported download numbers have been zero for a couple days now though I can't find the tweets anymore right now. I have no idea if this impacts relative numbers I assume it doesn't really, but just treat the above data with a grain of salt: npm isn't super reliable.

I realised we also did a survey (results can be found here) that also included a question about OS the participants would want to develop for (if I remember correctly).

This indicates 18.8% of survey participants are interested in developing apps for macOS, which requires using macOS to develop.
Again, this data is also skewed in all sorts of ways (mostly age breakdown, survey participants were overwhelmingly early in their careers)

But taken together I think it is safe to assume that roughly 15-25 percent of our user base regularly develop for macOS.

Note

Big grain of salt: There is no 1:1 relationship between people using macOS and people using Safari.
At least for the primarily frontend-developer, interested in Tauri it is safe to assume they have a second browser at least installed

Regardless of how big the Safari market share actually is, for those that are primarily safari users this means in the worst case:

1. clicking the link in the console
2. the web-ui opening in safari
3. an error popping up prompting them to download a different browser
4. the user downloading the browser, waiting for it to download and install
5. the user opening the link in that different browser

I hope this helps to illustrate how this impacts user velocity. Additionally, this would introduce a repeated slowdown for users if they don't want to set the new browser as their default: They would have to manually copy&paste the link every time.

Option 1

I don't have much input to give on option 1, except that it just screams nightmare to me as it would boil down to calling a command like this:

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ~/.localhost-ssl/localhost.crt

I would love input from our security experts here @tillmann-crabnebula @chip-crabnebula @felsweg-crabnebula

So based on this, what would be my recommendation?

Given our deadlines and the amount of features we want to ship, speed is paramount. Because of this I would recommend we just go with option 2 and not support Safari for the time being at least until we have decided how devtools shall be distributed in general at which point we should revisit this issue.
@atila-crabnebula and @david-crabnebula have indicated they agree with this direction.

[CrabNejonas]

I think @tejas-crabnebula has put this best:

[david-crabnebula]

Hey @CrabNejonas, thanks for the deep dive. Yeah, Safari can be a pain, right? I was thinking the same thing actually. We shouldn't let this slow us down.

I also want to point out that we're not the only ones using websockets for this sort of thing. Chromium, Deno, Node.js, and even Bun use it too. So, I don't think we should go all out trying to change it.

About the Safari issue, why don't we just bundle the UI into a Tauri app? This could be our go-to solution for Safari users or anyone else having issues with insecure websockets. Plus, it could be a cool feature if we decide to charge for the app later on. (could have a premium version with more features etc...)

Let's keep the ball rolling and not get stuck on browser issues.

[CrabNejonas]

About the Safari issue, why don't we just bundle the UI into a Tauri app?

If we do a Tauri app distribution I want us to do it right, not as an afterthought I so would like to just put this off for now.

As for the rest: Agreed 👍

[denjell-crabnebula]

Do we know that WKWebview on Safari will not have similar problems for Mac Users?

[denjell-crabnebula]

And we are planning on a Tauri app distribution target. This is why I asked Lucas to set one up here. Let's verify that it works (or doesn't) and go from there.

[CrabNejonas]

Do we know that WKWebview on Safari will not have similar problems for Mac Users?

I have been building apps with grpc-web in Tauri in the past no problems there, I assume the same goes for jsonrpc/websockets

[denjell-crabnebula]

can this issue be closed?

[CrabNejonas]

No the issue still stands, regardless of whether we use json-rpc or grpc or anything else we cannot connect from a website hosted on crabnebula.dev to a server listening on localhost

[denjell-crabnebula]

Is there a way for us to read from a recorded logfile? Use an intermediary service?