Yes, IsStartMenuShortcutWithActivatorGuidInstalled() logs something via metric Notifications.Windows.StartMenuShortcutStatus, BUT it's M69+ only. 

According to the Notifications.Windows.StartMenuShortcutStatus metric data, "(start menu) shortcut missing" is the most common case when SetReadyCallbackStatus is not SUCCESS.

My local testing shows that if an user has Chrome installed but start menu shortcut deleted and then installs Chrome without uninstalling it first, the start menu shortcut won't be created. So I think a Chrome update may not be able to automatically fix the issue of missing start menu shortcut.

Adding Greg to justify my understanding towards shortcut.

I just deleted the start menu shortcut for my Chrome (Stable channel) and then pulled the update for Chrome. The shortcut was not created during the update :-( 

Is it okay to "check and create if not present" the start menu shortcut during each Chrome update? 

+gab for shortcut question

i think our policy was to not create shortcuts on update since a lack of a shortcut likely meant the user deleted it and doesn't want it to reappear. since we have features that require a shortcut, maybe it's time to re-think this. Gab: do you remember any of this stuff? what are your thoughts?

The shortcut required by this feature is the start menu one. Maybe we can do something different on this shortcut from others like desktop shortcut etc?

Re. "and then installs Chrome without uninstalling it first, the start menu shortcut won't be created"

It seems reasonable to me to reinstall the shortcuts on "over-install" (installing over an existing install) but I'd be leary to do so on auto-update.

Currently this is driven by installer::InstallShortcutOperation.

FWICT, an over-install is already supposed to recreate the shortcuts:

InstallOrUpdateProduct(...) {
    (...)
    InstallShortcutOperation install_operation =
        INSTALL_SHORTCUT_REPLACE_EXISTING;
    if (result == FIRST_INSTALL_SUCCESS || result == INSTALL_REPAIRED ||
        !original_state.GetProductState(installer_state.system_install())) {
      // Always create the shortcuts on a new install, a repair install, and
      // when the Chrome product is being added to the current install.
      install_operation = INSTALL_SHORTCUT_CREATE_ALL;
    }


Having features depend on the presence of the start menu shortcut is unfortunate. If the shortcut becomes an implementation detail required to activate a feature; I'd suggest we create a separate one in a non-user-visible place to drive the feature.

Re: "FWICT, an over-install is already supposed to recreate the shortcuts"

Indeed. I tried again and this time it worked, regardless of the presence of the old shortcuts. I am not sure why it didn't work last time.

Thanks for the correction!

> Having features depend on the presence of the start menu shortcut is unfortunate.

Agreed. However, I believe this is out of our control because the shortcut requirement comes from the Windows APIs (I'm not aware of any way of registering a notification with the Action Center in Windows without the shortcut).

Unlike desktop shortcut which is visible to the user, the start menu shortcut is not. It is hidden in C:\ProgramData\Microsoft\Windows\Start Menu\Programs for Stable/Beta/Dev, or C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs for Canary/Chromium.

I think that the start menu shortcut is more likely to be deleted by some cleanup software accidentally than by the user. So reinstalling the start menu shortcut on auto-update seems fine to me. 

Code-wise this should be as simple as tweaking the InstallShortcutOperation for the Start menu shortcut. If a PM/UX person backs this then I'm fine with the code update.

+Mark for input.

Hi Mark, we want to know if it's okay to (re)install the start menu shortcut on Chrome auto-update. This shortcut is an implementation requirement for the native notification feature to work. Although this shortcut is hardly visible to the user (see comment 9), we found it is missing on some user machines based on the UMA metrics. Please find more details in the comments above.

WDYT please?

A quick note regarding comment 6's remark "Having features depend on the presence of the start menu shortcut is unfortunate." The old metro mode Win8 stuff also required a Start Menu shortcut, so this isn't exactly new. As mentioned in comment 8, the Start Menu shortcut is a hard requirement imposed by Windows.

To make matters a bit worse, I'll point out that we have the distribution.do_not_create_any_shortcuts master preference. It suppresses creation of the Start Menu shortcut for new installs. It has legitimate uses that we cannot ignore. If we'd create a missing shortcut on update, we'll have to check for a master_preferences file in the Application dir and make sure it doesn't suppress the shortcut.

To address the population of users who have installs that use that pref, we may need an in-product prompt to create the shortcut. Off the top of my head: does it make sense to detect that the shortcut is missing when a notification is posted so that Chrome can do something to its app menu that, when clicked, brings up a "notifications work better when Chrome has a tile in the Start Menu. click here to create one." bubble/dialog? Obviously, this would require some discussion with UX.

Let's not make this change at the moment. While it is unfortunate that notifications are not going to work, I don't want to override a user's preference for not having a the start menu shortcut. I can also understand there being enterprise reasons for having that master pref in the first place.

I'd propose we do two things:
1) monitor forum feedback around this issue so we know how annoying and prevalent it is.
2) consider adding help center content that describes how to mitigate

I will start email threads regarding those matters.

Won't fix per comment #13.