Issue 836914  has been merged into this issue.

 Issue 838918  has been merged into this issue.

 Issue 848068  has been merged into this issue.

IMO this should block the M68 beta for MacViews. The Omnibox not being usable is a pretty bad regression.

Issue 848432 has been merged into this issue.

Agreed with #8 - marking this as RB-Beta for MacViews rollout. 

sdy@, do we have any further update on the fix? since we are approaching M68 Beta this week.

M68 is going to beta on June 7th. 
Please land the fix to trunk ASAP and request a merge to M68 as this is blocking  MacViews experiment on M68 Beta. Thank you.

This should only affect MD refresh, which is not going out until M69, correct?

That's right, it should only affect MD Refresh.

 Issue 849562  has been merged into this issue.

This one's severe by the way - you can't do *anything* to the omnibox with suggestions visible. Please prioritize it :)

 Issue 852535  has been merged into this issue.

M69 branch is coming soon on July 19th, Your bug is marked as ReleaseBlock-Beta for M69. Please try to land the fix ASAP to trunk in order to prevent many merges going after M69 branch. This will also help us to branch M69 from high quality trunk. Thank you.

tommycli: Can this bug be load balanced to you?

 Issue 850574  has been merged into this issue.

Issue 853399 has been merged into this issue.

Load Balancing: I'll take a quick look into this.

Some notes: The Event Targeter is targeting OmniboxViewViews on Windows, and behaving correctly. On Mac, it appears to get a child of the RoundedOmniboxResultsFrame. That particular child doesn't care too much about mouse events and thus, the event is dropped on the floor.

Hey Rob - Sorry for the confusion here -- I think sdy@ is already investigating this.

The root cause is that on MacViews, there is no Aura, so we cannot use aura::WindowTargeter. 

https://cs.chromium.org/chromium/src/chrome/browser/ui/views/omnibox/rounded_omnibox_results_frame.cc?sq=package:chromium&g=0&l=156-162

Last time we videoconferenced, sdy@ was working on an alternative Mac-specific approach that will allow this to work even without Aura.

sdy@: is that still the case?

I had an initial approach but I've been a little overloaded, so I just briefed avi@ on this.

(avi@: this is the higher priority of the two halves of the issue, hopefully the window mask thing we discussed sorts it out on newer macOS, at least?)

Random notes from investigating in AppKit. On 10.11, making a window with NSResizableWindowMask doesn't allow clicking through, while making it with NSBorderlessWindowMask does. This is due to the edge resizing tracking areas; if you override -_resizesFromEdges to return NO, then you can click through even though the window is resizable. (That doesn't help if you want the window to be resizable but at least it slightly explains this.) Open question: do other tracking areas in the window prevent clicking through holes?

No, other tracking areas in the window don't prevent clicking through, even if the tracking area overlaps the hole.

_resizesFromEdges being NO allows clicking through, but why then?

Sidney and I worked on this today (on my Mac, 10.11 FYI), and here are our conclusions.

First, resizability shouldn't be an issue here, as the results frame shouldn't be resizable. (If it is, then that's a different issue that we'll need to address.)

Second, I think we hit the real problem.

If we use a CAShapeLayer to create a layer with a hole in the middle, you can click through the hole. However, if we use a CALayer and paint a transparent shape in the middle, you can't click through the hole. It's currently an open question whether punching a hole by using a CA masking layer works. (It's late here; we'll pick up investigation on Monday.)

This is bad. RoundedOmniboxResultsFrame::RoundedOmniboxResultsFrame() does actually try to punch a hole using a CC masking layer, but as far as we can tell, that gets rendered down to a transparent area.

Question 1: Does using a CA masking layer let you click through the hole in a window?

Question 2: If so, can we fix CC so that masking layers in CC translate to masking layers in CA?

Open question:

On Aura, we retarget the events to the underlying omnibox. Why can't we do that for the Mac? This seems like the easiest way forward.

avi: See c#30. There is no Aura on MacViews.

They MAY implement Aura past 69, but may not.

That is not the question I'm asking, though.

We can rewrite CC so that it properly keeps mask layers and translates them to CA masking layers. That might work. We can keep investigating that possibility.

But it's not like we *need* to get the event hole punching route working. We don't need events to flow to an arbitrary app on the other side of the hole. We know what's on the other side of that hole: the omnibox.

Yes, we use the event retargeting machinery that exists today in Aura to accomplish event transparency for the hole on the Mac. Can we build/write something equivalent for Views in general? I wonder if that would be an easier route than rewriting CC/CA integration.

avi: Gotcha that seems like a promising approach.

avi: This comment may help you: https://chromium-review.googlesource.com/c/chromium/src/+/974501#message-e1743c0878b5477256ae8b9037b3908c4548ec0b

sky@ refers to the event reposting logic used for context menus. We didn't pursue that because it was a large body of code and we were able to solve it a different way.

Re my earlier comment:

"Yes, we use the event retargeting machinery that exists today in Aura to accomplish event transparency for the hole on the Mac."

s/on the Mac/on Aura/ of course. Sorry for the confusion.

You refer to Scott's comment, which says "Reposting could be simplified if you only care about reposting to chrome windows." We only care about reposting to the omnibox, only that one view. Does that simplify the body of code we'd need to write?

avi: When I had investigated that approach a few months ago, I looked up how context menus repost events. It seemed fairly involved -- but you may have a different conclusion...

I don't know if I have a conclusion about its difficulty.

Given that we're not going to redesign this omnibox feature, it's either rewire layers and Core Animation, or reroute events.

I'm talking to Chris (ccameron) who points out that we're not guaranteed to have mask layers, so going the hole punching route in CA might not solve it all the time.

Sigh.

We're probably forced to event forward. Right now we have code to do that with Aura platforms. We'll have to do it at the Views level for the Mac, and I wonder if that work would subsume the Aura version.

I have a fix for event routing. The mouse pointer is still wrong.

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

commit ea805a9f49eeaa551cee6bf654bb4cefde1a89d3
Author: Avi Drissman <avi@chromium.org>
Date: Mon Jul 09 15:39:43 2018

Forward mouse events to the omnibox.

This allows the user to interact with the omnibox with mouse
events while the results pane is showing.

BUG= 836829 

Change-Id: Iec6eee4bf55ca82efdfdb5654f2fee86bd5975f5
Reviewed-on: https://chromium-review.googlesource.com/1128198
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#573318}
[modify] https://crrev.com/ea805a9f49eeaa551cee6bf654bb4cefde1a89d3/chrome/browser/ui/views/omnibox/rounded_omnibox_results_frame.cc

Able to reproduce the issue on chrome version 68.0.3406.0 (build without fix)
Verified the fix on Mac 10.13.5 using Chrome version # 68.0.3487.0 as per the comment #0.
Attaching screencast for reference.
Observed that "As we are able to edit the text "
The fix is working as expected, adding Verified labels

Thanks...!

Deleted: 836829.mp4 1.1 MB

	836829.mp4 1.1 MB View Download

This is fixed interaction-wise. The mouse cursor is broken, but I have a fix for that, https://chromium-review.googlesource.com/c/chromium/src/+/1130167 . However, that fix won't have any effect until mouse pointers are fixed in non-top-level windows, which is  bug 851834 . Closing this in the meanwhile.

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

commit 31de41a5cd7078ec8bc0b8bbb2dc82543a59f217
Author: Avi Drissman <avi@chromium.org>
Date: Wed Jul 11 23:54:41 2018

Fix the mouse pointer for the omnibox.

While the results pane is showing, forward cursor requests to the
underlying omnibox.

Note that this won't actually show any changes until 851834 is fixed.

BUG= 836829 , 851834 

Change-Id: I9928fe8f690cc27f1844dbe1c0b3dae08082706d
Reviewed-on: https://chromium-review.googlesource.com/1130167
Commit-Queue: Avi Drissman <avi@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574416}
[modify] https://crrev.com/31de41a5cd7078ec8bc0b8bbb2dc82543a59f217/chrome/browser/ui/views/omnibox/rounded_omnibox_results_frame.cc