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

Issue 721384 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression

Blocking:
issue 709765



Sign in to add a comment

is_browser_shortcut in WebKeyboardEvent is broken (always false)

Project Member Reported by a...@chromium.org, May 11 2017

Issue description

This regressed some time in the past month.

I suspect https://codereview.chromium.org/2781633003/ as that's the only thing that's touched this code recently. Am investigating.
 

Comment 1 by a...@chromium.org, May 11 2017

Labels: OS-Mac
This is broken at least on the Mac, but I don't know other platforms. I'm planning on writing a test, which will help me discover where it's broken and prevent it from regressing once fixed.
ToT on Linux returns true for: Ctrl-S 
It's a Mac OS only change at https://codereview.chromium.org/2824803004/diff/40001/chrome/browser/ui/cocoa/browser_window_cocoa.mm. I believe the original implementation is not correct, returning true from e. BrowserCommandController::IsReservedCommandOrKey() indicates the event is a browser shortcut.

Comment 4 by a...@chromium.org, May 11 2017

ToT on Mac returns false for Command-S. Probably Mac-only.

I have some ideas in mind on how to write a test. I'll write it and run it by you.
There are some keyboard tests that predate me that I tried to reactivate (see https://codereview.chromium.org/2246913002/) but haven't gotten around to it. They were broken on Mac and I didn't have a Mac at the time. Not sure if they can be extended to cover the shortcut functionality.

Comment 6 by a...@chromium.org, May 11 2017

My first attempt at a test is https://codereview.chromium.org/2874313002 but it's showing Linux as failing when you are saying that it works. I'll give the test another try tomorrow, but perhaps you can see why it's not working.
I would suggest to submit change https://codereview.chromium.org/2874153004/ first to revert the behavior to its original state first.

Comment 8 by a...@chromium.org, May 12 2017

I would follow whatever Dave recommends re the revert, but this still needs a test.
Project Member

Comment 9 by bugdroid1@chromium.org, May 12 2017

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

commit fc91a3995bfd7cf39ce78b3b7d6fe69feadb9f34
Author: zijiehe <zijiehe@chromium.org>
Date: Fri May 12 17:47:44 2017

Revert change to BroserWindowCocoa::PreHandleKeyboardEvent in 2824803004

BUG= 721384 

Review-Url: https://codereview.chromium.org/2874153004
Cr-Commit-Position: refs/heads/master@{#471357}

[modify] https://crrev.com/fc91a3995bfd7cf39ce78b3b7d6fe69feadb9f34/chrome/browser/ui/cocoa/browser_window_cocoa.mm

Comment 10 by a...@chromium.org, Jun 23 2017

Status: Fixed (was: Started)
Sorry for the delay. I have confirmed that the revert has fixed this. Marking as fixed, and I will be creating a test to prevent a regression.

Sign in to add a comment