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

Issue 912712 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Out until 24 Jan
Closed: Dec 11
Cc:
EstimatedDays: ----
NextAction: 2018-12-10
OS: Windows
Pri: 1
Type: Bug



Sign in to add a comment

[Regression] Opening a doc from a Google drive link leads to unresponsive keyboard state

Project Member Reported by aleventhal@chromium.org, Dec 6

Issue description

Bisect for the regression: https://chromium-review.googlesource.com/c/chromium/src/+/1286194

Steps:
- Open a Google Drive folder
- Navigate to a document in the file list (you can single click on it, but don't open it yet)
- Hit Enter to open the document

What happens:
- After the document opens in a new tab, pressing arrow down does nothing, typing letters to insert text does nothing, etc.
- Also note that the caret stops blinking after 1-2 blinks

Expected:
- Document opens in new tab, caret remains blinking, and key commands work

Related / same cause: 912348
 
Description: Show this description
Simple test case attached -- the first link does not properly focus the text field on google.com, but the second one works.
window-open.html
200 bytes View Download
Project Member

Comment 3 by bugdroid1@chromium.org, Dec 7

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

commit 28ebd5bc2acb2b87566d1af5e4c907b8761b5b17
Author: Nasko Oskov <nasko@chromium.org>
Date: Fri Dec 07 22:29:33 2018

Focus newly opened window when noopener is specified.

When r601148 was committed, the codepath for window.open() and link
clicks that result in a new window with 'noopener' attribute was changed
to avoid going to the embedder with OpenURL. The result was that the
newly created window was no longer focused, which was done previously
as a side effect of OpenURL calling chrome::Navigate.

This CL adds focusing in the changed codepath to restore this behavior.

Bug:  912348 ,  912712 
Change-Id: Ia4f5b58a71cbe86bc28b434c0b0501b156c64bc1
Reviewed-on: https://chromium-review.googlesource.com/c/1367164
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#614847}
[modify] https://crrev.com/28ebd5bc2acb2b87566d1af5e4c907b8761b5b17/chrome/browser/chrome_navigation_browsertest.cc
[modify] https://crrev.com/28ebd5bc2acb2b87566d1af5e4c907b8761b5b17/content/browser/web_contents/web_contents_impl.cc

Cc: -nasko@chromium.org aleventhal@chromium.org
NextAction: 2018-12-10
Owner: nasko@chromium.org
Given this is rated as P1, I'll let it bake on canary over the weekend and request merge to M72 on Monday.
The NextAction date has arrived: 2018-12-10
Labels: Merge-Request-72
I checked for crashes and see none, so far I haven't seen bugs filed related to this, so let's merge it in M72.
Labels: -Merge-Request-72 Merge-Approved-72
branch:3626
Project Member

Comment 9 by bugdroid1@chromium.org, Dec 11

Labels: -merge-approved-72 merge-merged-3626
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4b19c2bc3201067ed352d0b09d341259015220cc

commit 4b19c2bc3201067ed352d0b09d341259015220cc
Author: Nasko Oskov <nasko@chromium.org>
Date: Tue Dec 11 02:45:57 2018

[M72 merge] Focus newly opened window when noopener is specified.

When r601148 was committed, the codepath for window.open() and link
clicks that result in a new window with 'noopener' attribute was changed
to avoid going to the embedder with OpenURL. The result was that the
newly created window was no longer focused, which was done previously
as a side effect of OpenURL calling chrome::Navigate.

This CL adds focusing in the changed codepath to restore this behavior.

Bug:  912348 ,  912712 
Change-Id: Ia4f5b58a71cbe86bc28b434c0b0501b156c64bc1
Reviewed-on: https://chromium-review.googlesource.com/c/1367164
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#614847}
Reviewed-on: https://chromium-review.googlesource.com/c/1371201
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#249}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}
[modify] https://crrev.com/4b19c2bc3201067ed352d0b09d341259015220cc/chrome/browser/chrome_navigation_browsertest.cc
[modify] https://crrev.com/4b19c2bc3201067ed352d0b09d341259015220cc/content/browser/web_contents/web_contents_impl.cc

Status: Fixed (was: Started)
Labels: Merge-Merged-72-3626
The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/4b19c2bc3201067ed352d0b09d341259015220cc

Commit: 4b19c2bc3201067ed352d0b09d341259015220cc
Author: nasko@chromium.org
Commiter: nasko@chromium.org
Date: 2018-12-11 02:45:57 +0000 UTC

[M72 merge] Focus newly opened window when noopener is specified.

When r601148 was committed, the codepath for window.open() and link
clicks that result in a new window with 'noopener' attribute was changed
to avoid going to the embedder with OpenURL. The result was that the
newly created window was no longer focused, which was done previously
as a side effect of OpenURL calling chrome::Navigate.

This CL adds focusing in the changed codepath to restore this behavior.

Bug:  912348 ,  912712 
Change-Id: Ia4f5b58a71cbe86bc28b434c0b0501b156c64bc1
Reviewed-on: https://chromium-review.googlesource.com/c/1367164
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#614847}
Reviewed-on: https://chromium-review.googlesource.com/c/1371201
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#249}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}

Sign in to add a comment