Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
milke opened this issue Dec 28, 2023 · 5 comments
Closed

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

milke opened this issue Dec 28, 2023 · 5 comments

Comments

@milke
Copy link

milke commented Dec 28, 2023

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?

@milke milke changed the title Release notes based on currently installed version in legacy WebVIew Release notes based on currently installed version in legacy WebView Dec 28, 2023
@zorgiepoo
Copy link
Member

zorgiepoo commented Dec 28, 2023

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
Copy link
Member

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
Copy link
Member

zorgiepoo commented Dec 29, 2023

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
Copy link
Author

milke commented Dec 29, 2023

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 feedback-assistant/reports#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
Copy link
Member

@milke see also #2514 for recent issues I'm resolving with the downloader service.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants