New issue
Advanced search Search tips

Issue 838966 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

Support command-enter in omnibox on Mac

Project Member Reported by jdonnelly@chromium.org, May 2 2018

Issue description

With the Cocoa omnibox, the selected suggestion would be opened in a new background tab on command-enter. (Safari also does this.) With MacViews, command-enter now does the same thing as alt-enter: opens the suggestion in a new foreground tab.

Assigning to ellyjones to answer the question of whether we care about re-implementing the old behavior.

It's probably not difficult to add this behavior but it runs the risk of introducing subtle bugs like the old implementation had (https://crbug.com/513966 and then  https://crbug.com/743288  when I tried to fix the first one).
 
Cc: -jdonnelly@chromium.org ellyjo...@chromium.org
Labels: M-69 MacViews-Browser Target-69
Owner: jdonnelly@chromium.org
I'd say we probably should not regress this. Let's do the fix and take the subtle-bug risk.
Ok, sounds good, I'll take care of this.
Status: Started (was: Assigned)
Summary: Support command-enter in omnibox on Mac (was: Support command-enter in omnibox on Mac?)
Sending a CL out for review: https://crrev.com/c/1049949.

The behavior looks good and is improved over the Cocoa omnibox experience. In the latter, when you switch tabs after command-enter, the omnibox restores the current page URL but still leaves you in the edit state with the cursor in what feels like a semi-random position. It's weird. In MacViews, with this change, the edit state is fully preserved after command-enter. It is also fully preserved when switching between tabs, meaning that crbug/743288 does not occur.

Tested with and without the following flags:
chrome://flags/#top-chrome-md
chrome://flags/#views-browser-windows
chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains
Project Member

Comment 5 by bugdroid1@chromium.org, May 8 2018

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

commit 61f29c23936f92aaac874e4dea2d247b71497f15
Author: Justin Donnelly <jdonnelly@google.com>
Date: Tue May 08 14:38:38 2018

[omnibox, MacViews] Open background tab on command-enter.

Previously, this opened a new tab in the foreground. Opening in a
background tab matches the behavior of Cocoa Chrome and Safari.

Bug:  838966 
Change-Id: I5220c614afab0fc1894af0f39caa350529ef7634
Reviewed-on: https://chromium-review.googlesource.com/1049949
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Justin Donnelly <jdonnelly@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556794}
[modify] https://crrev.com/61f29c23936f92aaac874e4dea2d247b71497f15/chrome/browser/ui/views/omnibox/omnibox_view_views.cc

Status: Fixed (was: Started)
Labels: TE-Verified-68.0.3425.0 TE-Verified-M68
Able to reproduce this issue on Mac OS 10.12.6 on the build without fix 68.0.3418.0 and the issue is fixed on the latest Canary 68.0.3425.0.

By enabling #views-browser-windows flag, can observe that on hitting command-enter on a selected text, it is opened in a background tab.
Attached is the screen shot for reference.

Hence adding TE verified labels as the fix is working as intended.

Thanks..
838966.mp4
960 KB View Download

Sign in to add a comment