This is pretty nasty. I think anyone who has signed in will have this problem as we install hosted apps by default, is that right?

> I think anyone who has signed in will have this problem as we install hosted apps by default, is that right?

Hosted apps: no
Packaged apps: yes
Bookmark apps: yes (when a user creates them, which they can't without flipping a flag).

So, a Googler will get gnubbyd, but that's an enterprise config.

Just tested signing in on a clean user data dir. On startup, gnubby got created, but not the other default-installed hosted apps.

On signin, the bookmark apps I had created while chrome://flags/#disable-new-bookmark-apps was enabled were synced, and they got shims. However, other hosted apps (e.g. Maps) did not get shims. Installing a new hosted app from the webstore also did not create a shim.

OK, bumping priority down then.

Given that this was filed by Apple, it's likely enough users are seeing this that it caused them concern. Can we get a sense of how many people would be affected?

Trent - is there anyone available to fix this (yourself, Patti, Karan) for M53?

Note I'm not sure whether a "full" fix is readily achievable in a short timeframe. If Spotlight always uses the pathname we're kinda stuffed. Based on the snippets in that email, it seems likely that it does, but I can do some experiments with the "basic" fix to check.

Changing the path of the .app shim to something "proper" is super hard. E.g. we need a strategy to deal with name collisions (both the same app in different profiles, and different apps with the same name in the same profile). And renames (both app name renames and possibly profile "name" renames).

So even my "basic" fix fell flat. It actually causes a regression.

https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/20001431-110725

says
<quote>
  CFBundleDisplayName (String - iOS, OS X) specifies the display name of the bundle. If you support localized names for your bundle, include this key in both your information property list file and in the InfoPlist.strings files of your language subdirectories. If you localize this key, you should also include a localized version of the CFBundleName key.

  If you do not intend to localize your bundle, do not include this key in your Info.plist file. Inclusion of this key does not affect the display of the bundle name but does incur a performance penalty to search for localized versions of this key.

  Before displaying a localized name for your bundle, the Finder compares the value of this key against the actual name of your bundle in the file system. If the two names match, the Finder proceeds to display the localized name from the appropriate InfoPlist.strings file of your bundle. If the names do not match, the Finder displays the file-system name.
</quote>

That last para is the regression. If I attempt to set CFBundleDisplayName in the non-localized plist, Finder goes "hey, that's different to the file path, I'm going to ignore your localizations completely and just display the file-system name".


So I think to fix this we need to completely re-architect how the filenames are chosen: base it off the actual extension title: sanitize it (e.g. remove slashes and dots), deal with conflicts, deal with renames, etc., etc.

Deprecating UI>OSIntegration in favor of the more generic Internals>PlatformIntegration

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Polish issue that should be fixed for Mac desktop PWAs.

Need discussion to decide what the best behaviour is here. (Will need to decide with the Mac team.)

Brief discussion: We would rather fix Spotlight for all apps (as a P1), but dealing with duplicate app names can be a P2.

When a PWA is installed, the .app is created in two locations -- see:
https://cs.chromium.org/chromium/src/chrome/browser/web_applications/components/web_app_shortcut_mac.mm?rcl=17a16051a91dbf3713860c3e90bf06e0e3dd0a8e&l=617

One is in ~/Applications
- This one appears in spotlight searches
- This is the one that we try to launch when launching from chrome://apps (or elsewhere in the browser)

The other is in ~/Library/Application\ Support/Google/Chrome/(bunch-o-stuff)
- This does not appear in spotlight searches
- This one we will use if we fail to find the one in ~/Applications (which the user can rename, move, etc)

It strikes me that we should consider using a non-app-id .app name for the .app created in ~/Applications.

Another option I want to consider is using a symlink in ~/Applications
- This works correctly with Launchpad (the application appears when searched for)
- This is broken in Spotlight (the application does not appear)
  - It appears Spotlight does not index symlinks

Wrote up more details about this in 
https://docs.google.com/document/d/1U1yOH2XlsWW5fO63w0MAXWjjZewvE5XTAP4V-6YTGBc/edit?usp=sharing

This affects launch pad as well.

Bulk downgrading some bugs to P2.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f4dc2a844a6b7d2461a402738525d8614071d50a

commit f4dc2a844a6b7d2461a402738525d8614071d50a
Author: Christopher Cameron <ccameron@chromium.org>
Date: Wed Jan 09 11:09:41 2019

MacPWAs: Use app titles for app names

Prior to this change, installed PWAs would have names such as
"Profile 5 cgecgkkjhjfcokpghlckjpopjpmekpjc.app" instead of
"Killer Marmot.app". Localization is used to make the display name for
the application in Finder be prettier.

Note that the above scheme avoids conflicts between apps that share the
same name (because they will have different extension ids) and instances
of the same app under different profiles (because the profile is also
part of the name).

In this change, default to using the PWA title as the app name in the
filesystem. Before installing an app, check to see if the desired path
already exists and, if so, change the application path by appending a
number, e.g. "Killer Marmot 2.app". If somehow we find ourselves in
the situation of writing "Killer Marmot 99.app", then fall back to the
old scheme.

Bug: 616301
Change-Id: Iaf333b4eceb770a3f6cf344c02900b0fccf915e7
Reviewed-on: https://chromium-review.googlesource.com/c/1400158
Commit-Queue: ccameron <ccameron@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621111}
[modify] https://crrev.com/f4dc2a844a6b7d2461a402738525d8614071d50a/chrome/browser/web_applications/components/web_app_shortcut_mac.h
[modify] https://crrev.com/f4dc2a844a6b7d2461a402738525d8614071d50a/chrome/browser/web_applications/components/web_app_shortcut_mac.mm
[modify] https://crrev.com/f4dc2a844a6b7d2461a402738525d8614071d50a/chrome/browser/web_applications/components/web_app_shortcut_mac_unittest.mm