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

Issue 753238 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome
Pri: 3
Type: Feature

Blocked on:
issue 764626

Blocking:
issue 740783



Sign in to add a comment

DesktopPWAWindowing: Middle-click app link should not open a blank tab

Project Member Reported by mgiuca@chromium.org, Aug 8 2017

Issue description

Chrome Version: 62 (post r492505)
OS: Windows, Linux, CrOS

What steps will reproduce the problem?
(1) Run with --enable-features=DesktopPWAWindowing
(2) Install the app https://killer-marmot.appspot.com/web (Add to Desktop, Open in Window)
(3) Go to https://killer-marmot.appspot.com.
(4) Middle-click "Web app".

What is the expected result?
Opens the app in a window.

What happens instead?
Opens a new tab on that URL, loads the background colour but doesn't load any of the rest of the page, THEN opens the app in a window.

It should not open a browser tab at all.

Related: Right-click -> open in tab should actually open in a tab, not the app window. That's part of a more advanced feature request, though (to add a separate "open in app" context menu link), which doesn't need to be resolved now.
 
Labels: -Type-Bug-Regression Type-Feature
Ah yup. We basically need a set of if statements to decide if we should close the web contents where the navigation is happening.
Components: UI>Browser>WebAppInstalls

Comment 3 by ortuno@chromium.org, Sep 13 2017

Blockedon: 764626
Project Member

Comment 4 by bugdroid1@chromium.org, Oct 12 2017

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

commit f2bd12747d263b209a389fdca4470aa6052a9edd
Author: Giovanni Ortuño Urquidi <ortuno@chromium.org>
Date: Thu Oct 12 03:16:12 2017

desktop-pwas: Post task to open the app and another one to close the tab

When a new WebContents has no opener, the first navigation will happen
synchronously. This could result in us opening the app and then focusing
the original WebContents. To avoid this we post a task to open the app.

According to NavigationThrottle::WillStartRequest's documentation closing
a WebContents should be done asynchronously to avoid UAFs.

Bug:  753238 ,  764607 
Change-Id: Ib0a62a33dff78cae7a0a90f19db77becacc8aeb9
Reviewed-on: https://chromium-review.googlesource.com/691635
Reviewed-by: Ben Wells <benwells@chromium.org>
Reviewed-by: Matt Giuca <mgiuca@chromium.org>
Commit-Queue: Giovanni Ortuño Urquidi <ortuno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508240}
[modify] https://crrev.com/f2bd12747d263b209a389fdca4470aa6052a9edd/chrome/browser/extensions/bookmark_app_navigation_throttle.cc
[modify] https://crrev.com/f2bd12747d263b209a389fdca4470aa6052a9edd/chrome/browser/extensions/bookmark_app_navigation_throttle.h
[modify] https://crrev.com/f2bd12747d263b209a389fdca4470aa6052a9edd/chrome/browser/extensions/bookmark_app_navigation_throttle_browsertest.cc

Comment 5 by ortuno@chromium.org, Nov 15 2017

Status: Fixed (was: Assigned)

Sign in to add a comment