New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 746781 link

Starred by 2 users

Issue metadata

Status: Archived
Owner: ----
Closed: Sep 11
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Desktop: Add to Desktop creates the shortcut twice simultaneously

Project Member Reported by mgiuca@chromium.org, Jul 20 2017

Issue description

Chrome Version: 61 (r487021)
OS: Linux (suspect Windows, Mac? also)

What steps will reproduce the problem?
(1) Add a log in web_app_PLATFORM.cc's CreatePlatformShortcuts.
(2) Visit a web page.
(3) Menu -> More tools -> Add to desktop

What is the expected result?
CreatePlatformShortcuts is called once.

What happens instead?
CreatePlatformShortcuts is called TWICE!

Control flow:

UI thread:
...

-> [extension_service.cc] ExtensionService::FinishInstallation
   [extension_registry.cc] ExtensionRegistry::TriggerOnWillBeInstalled
   [shortcut_manager.cc] AppShortcutManager::OnExtensionWillBeInstalled
   [web_app.cc] UpdateAllShortcuts
   [web_app.cc] UpdateAllShortcutsForShortcutInfo
   -> (PostIOTaskAndReply: UpdatePlatformShortcuts)
...
-> [create_application_shortcut_view.cc] CreateChromeApplicationShortcutView::Accept
   [web_app.cc] CreateShortcutsWithInfo
   [web_app.cc] ScheduleCreatePlatformShortcut
   -> (PostIOTaskAndReply: CreatePlatformShortcuts)

Task 1:
[web_app_linux.cc] UpdatePlatformShortcuts
[web_app_linux.cc] CreatePlatformShortcuts

Task 2:
[web_app_linux.cc] CreatePlatformShortcuts

It looks like something (presumably the sorta-recent bookmark-apps-as-extensions code) installs an extension which creates a shortcut --- I can't find exactly where that is triggered. The old Accept button on the Create Application Shortcuts view also creates a shortcut.

Technically no harm done (they overwrite one another, and there's no race with the images because they are loaded into a new ImageFamily) but wasteful, complex and potentially racy in the file system.
 

Comment 1 by mgiuca@chromium.org, Jul 20 2017

Cc: ortuno@chromium.org
+ortuno do we want to escape this madness?
When does the first call happen? Is it when the dialog is first created? A while back, the extension was created when Add to desktop was clicked (i.e on dialog show). This would install the extension, which was then uninstalled on dialog cancel, to mimic the behavior of Bookmarks (Esc cancels but installs, Remove actually removes).

A second call to install would happen on dialog accept which actually updated the app name and the accompanying shortcut creation would update all shortcuts.

AFAICT, this flow seems to no longer be true (no extension is installed on dialog show, which is definitely how we want PWAs to work). If extension creation happens on dialog accept, this second call is no longer necessary.

Comment 3 by mgiuca@chromium.org, Jul 20 2017

#2 Both calls happen on dialog accept.

I haven't traced back far enough to understand how the ExtensionService code gets run... presumably it would be called from the Accept() method but it isn't in the stack trace of ExtensionService::FinishInstallation.

I agree that if we do want to delete one of these, it's probably the direct call to CreateShortcutsWithInfo (to let the extension code continue to work as-is).
Components: UI>Browser>WebAppInstalls
Project Member

Comment 5 by sheriffbot@chromium.org, Sep 10

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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
Status: Archived (was: Untriaged)
Please reopen as necessary

Sign in to add a comment