Safari workaround instructions out of date

[jaknz]

This issue needs to be revisited. None of these menus or options exist on macOS or iOS today, and I haven’t been able to find the equivalent in the new settings.

#410

On iOS, there is no longer an Experimental Features submenu. There is now a Webkit Feature Flags section, but there’s nothing like NSURLSession WebSocket listed there. Maybe they’ve given it a human-friendly name, but it’s not obvious what that is.

Similar issue on macOS; the Develop menu no longer has an Experimental Features dropdown at all. Feature flags have been moved into the settings window, but again there’s nothing that obviously matches with the needed flag.

[martinpitt]

Thanks -- if you or anyone else finds out how to do this on current Safari now, please let us know. We don't test on/support Safari, as it's not available for installation and testing under Linux.

[garrett]

You haven't needed to do that for a few years, though? Safari was fixed; the workaround was for older versions. It hasn't been relevant for a while.

Oh, right; that was the old buggy Safari TLS handling in iOS and macOS. They fixed it and everything was fine for a while. Then they broke it again, but just on M1/M2 devices (which I cannot test in a VM) and on newer iOS (which I also cannot test, as I have an iPhone 7, which stopped getting updates a while ago at this point in time).

I'll ask around.

Meanwhile, if you're having problems by default and if you can figure out a similar workaround and can take photos, that would be a wonderful contribution. I'm happy to help edit the screenshots.

[garrett]

Note: This particular issue was with one of the few things we couldn't actively test on Linux. For most rendering with Safari, 99% of that is shared in common with WebKitGTK, which we can and do test and fix on Linux. Cockpit Client, our desktop app for Linux that is distributed via Flatpak, even uses WebKitGTK... so we do actually test WebKit.

This in particular is Safari having their own weird, buggy TLS implementation that differs across OS and architecture, apparently.

(It's especially annoying given how there's really only one web browser on iOS and iPadOS. Everything's only WebKit plus the Safari network stack.)

[garrett]

Just for reference: Latest version of Safari (16.1) works without any workarounds (I made sure to remove my ~/Library/*Safari* folders) on macOS (Monterey in a VM on x86):

Granted, it's an older version of macOS (both major and minor version), as installing and updating takes ages, especially on my laptop. But this is the most up-to-date Safari — but on an Intel CPU, not an ARM (Apple's M1, M2, or M3).

I've asked for help confirming the status with an M2.

[garrett]

@marusak confirms that a previously-unused Safari on macOS on a brand new Mac also works fine with Cockpit.

I really don't think macOS needs the workaround anymore? We should probably remove the warning on the installation screen, if so.

Or, if it does seem to still need it in some cases, could you please let us know more details, such as your OS and browser versions, please? Thanks!