<rdar://problem/62075201>
Created attachment 397036 [details] Patch
Created attachment 397039 [details] Patch
Comment on attachment 397039 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=397039&action=review > Source/WebKit/ChangeLog:10 > + Give the WebContent XPC service bundle a localizable CFBundleDisplayName to make it > + more easily identifiable. WebContent sets its name dynamically, that's how it uses webpage domain name for Safari, or includes "Mail" in the name for Mail. Adding a static way to do the same appears confusing and thus undesirable.
(In reply to Alexey Proskuryakov from comment #3) > Comment on attachment 397039 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=397039&action=review > > > Source/WebKit/ChangeLog:10 > > + Give the WebContent XPC service bundle a localizable CFBundleDisplayName to make it > > + more easily identifiable. > > WebContent sets its name dynamically, that's how it uses webpage domain name > for Safari, or includes "Mail" in the name for Mail. > > Adding a static way to do the same appears confusing and thus undesirable. Some frameworks are only able to read names statically declared in the Info.plist of an executable (or XPC binary in this case). Since these frameworks are unable to retrieve the dynamic name nonetheless, wouldn't it make sense to at least have a reasonable fallback attribution to avoid user confusion?
This depends on how the default is used. What seems like a reasonable fallback in one scenario can end up confusing users or being a security problem in another scenario. Obviously, not everything displayed by WebContent is a website. On the technical level, I'm not sure about the implications: 1. How does CFBundleDisplayName interact with _kLSDisplayNameKey. Looks like we may get away for now with using one on macOS and another on iOS (but unsure what macCatalyst should do). But that seems fragile. 2. What else is CFBundleDisplayName used for. How bad is it to get "Website" as the name in those situations? Documentation says "The user-visible name for the bundle, used by Siri and visible on the iOS Home screen", and "Use this key if you want a product name that's longer than CFBundleName."
Created attachment 397446 [details] Patch
Created attachment 397447 [details] Patch
Created attachment 397448 [details] Patch
Created attachment 397451 [details] Patch
Comment on attachment 397451 [details] Patch r=me
Committed r260650: <https://trac.webkit.org/changeset/260650> All reviewed patches have been landed. Closing bug and clearing flags on attachment 397451 [details].
Comment on attachment 397451 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=397451&action=review > Source/WebKit/Scripts/process-entitlements.sh:155 > + plistbuddy Add :com.apple.security.exception.mach-lookup.global-name array > + plistbuddy Add :com.apple.security.exception.mach-lookup.global-name:0 string com.apple.systemstatus.activityattribution Is this also needed when issuing the extension?
(In reply to Per Arne Vollan from comment #12) > Comment on attachment 397451 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=397451&action=review > > > Source/WebKit/Scripts/process-entitlements.sh:155 > > + plistbuddy Add :com.apple.security.exception.mach-lookup.global-name array > > + plistbuddy Add :com.apple.security.exception.mach-lookup.global-name:0 string com.apple.systemstatus.activityattribution > > Is this also needed when issuing the extension? Oh yeah, this looks like a mistake. The purpose of the extension is to avoid generally enabling access to this service in the WebContent process.
Re-opened since this is blocked by bug 211172
Created attachment 397946 [details] Patch
Committed r260904: <https://trac.webkit.org/changeset/260904> All reviewed patches have been landed. Closing bug and clearing flags on attachment 397946 [details].