Release notes based on currently installed version in legacy WebView

milke commented 8 months ago

I'm trying to show only the relevant release notes, as explained here. I have this specified in my release_notes.html:

<head>
    <style>
    div.sparkle-installed-version {
        opacity: 0.5;
    }
    div.sparkle-installed-version ~ div {
        display: none;
    }
    </style>
</head>

And then each new release note defined as:

<div data-sparkle-version="3">
    <p><b>Changes in version 1.2:</b></p>
    <ul>
    <li>Feature 3.</li>
    <li>Feature 4.</li>
    </ul>
</div>

This all works fine as documented in WKWebView, but not in legacy WebView (when using Downloader.xpc and without having com.apple.security.network.client entitlement defined for sandboxed application). Legacy WebView displays ALL release notes (without opacity), completely ignoring div.sparkle-installed-version style definitions. So, before checking the source code, I wonder if this is the (known?) limitation of legacy WebView, or there is in code some additional configuring done for WKWebView, but omitted for legacy WebView?

zorgiepoo commented 8 months ago

It's a known limitation; I am not sure what it would take to port it over. I suppose we can indeed document it on the website. Frankly I am surprised someone is using the Downloader XPC Service (it's not commonly used as most sandboxed apps require network usage).

Sparkle uses deprecated WebKit1 when opting into the Downloader XPC Service all thanks to WebKit not fixing a bug preventing the sandboxed app from being able to use WKWebView without com.apple.security.network.client. If you can, please file a Feedback Assistant or bug report (I guess WebKit also uses Bugzilla?) to them illustrating how it's important for your app and how it blocks adoption from WebKit1 -> WebKit2.

The only current way of using the Downloader XPC Service without legacy WebKit1 is using plain text release notes or markdown if that's implemented in the future (#2319). However these are definitely not what you want if you want to stylize release notes like you posted.

zorgiepoo commented 8 months ago

So, before checking the source code, I wonder if this is the (known?) limitation of legacy WebView, or there is in code some additional configuring done for WKWebView, but omitted for legacy WebView?

For clarification, there is additional code done for configuring WKWebView which inserts javascript (see _userScriptForExposingCurrentRelease). However, I do not know if it's possible to carry this over to WebView the same way. We can leave this issue open for that.

zorgiepoo commented 8 months ago

I took a brief look at this a bit. I think it's only possible to carry this over to WebView if you leave javascript enabled everywhere. But I don't want to encourage a configuration that requires enabling javascript globally (other than small scripts that Sparkle injects, which WKWebView was designed in mind for). So I'm going to mark this issue as a "known limitation". The future paths forward are escalating to WebKit on fixing their bug and/or using the network entitlement for your app without the downloaded XPC Service if this feature is important for you.

I updated the website documentation as well.

milke commented 8 months ago

I am surprised someone is using the Downloader XPC Service (it's not commonly used as most sandboxed apps require network usage).

It's quite simple: I want to use Sparkle for updating of an sandboxed application, which doesn't require com.apple.security.network.client (and I don't want to add that entitlement just for the updater, if Downloader.xpc can already do the job).

Sparkle uses deprecated WebKit1 when opting into the Downloader XPC Service all thanks to WebKit https://github.com/feedback-assistant/reports/issues/1 preventing the sandboxed app from being able to use WKWebView without com.apple.security.network.client. If you can, please file a Feedback Assistant or bug report (I guess WebKit also uses Bugzilla?) to them illustrating how it's important for your app and how it blocks adoption from WebKit1 -> WebKit2.

I know all the reasons and about the bug. I've already filed a duplicate about 2 months ago. But knowing Apple… 😐 They may easily claim it "a feature" 🙂

I took a brief look at this a bit. I think it's only possible to carry this over to WebView if you leave javascript enabled everywhere.

I looked into the code and that seems the only option, but I agree it isn't a very good idea. Certainly not for just enabling such limited feature, like conditionally styled release notes.

So, I'll do what I've been doing until now; pass some additional parameter (kCFBundleVersionKey) to the appcast. which in turn will pass it to release notes script, which will output the correct release notes, based on updater version (kCFBundleVersionKey) and beta/stable channel. The only difference is that before I modified Sparkle framework for that (I'm one of the earliest adopters of your great work on pre-2 version of Sparkle, which could update sandboxed application using separated XPC services) and now I'll use -feedParametersForUpdater:sendingSystemProfile:.

Thanks for checking it out anyway 👍🏻

zorgiepoo commented 6 months ago

@milke see also https://github.com/sparkle-project/Sparkle/discussions/2514 for recent issues I'm resolving with the downloader service.

sparkle-project / Sparkle

Release notes based on currently installed version in legacy WebView #2482