[Webkit-unassigned] [Bug 278284] WKWebView version not available in API and not included in user agent for macOS
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Aug 20 09:44:54 PDT 2024
https://bugs.webkit.org/show_bug.cgi?id=278284
--- Comment #2 from Steve Repsher <steverep+webkit at gmail.com> ---
(In reply to Karl Dubost from comment #1)
> What are the scenarios you are trying to solve with the user agent string,
> which are not possible with features detection?
TBH, I'm not sure what that question has to do with the merit of the report? But to divulge for a moment, my primary use case is for an open source app called Home Assistant. We have a build for modern browsers, and a heavily transpiled and polyfilled build for legacy browsers. While we use feature detection as backup, splitting based on known browser version is far more convenient and virtually free of maintenance over time.
> Understanding the use cases for the version number will help.
Safari browser on every platform currently sends the correct version in the user agent header. A WKWebView on iPhone and iPad does the same. So, I don't understand the need for justification of its use here when WebKit is already doing it. This report is simply pointing out the discrepancy with WKWebView on macOS, and the inability of app authors to manually retrieve it with the current API. That seems like an oversight rather than a conscious choice by Apple, no?
Similarly, modifying this bug to depend on the implementation of client hints also makes zero sense to me. Unless I'm really missing something, in no way do either of the solutions requested depend on that.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240820/2158de63/attachment.htm>
More information about the webkit-unassigned
mailing list