Note: this bug doesn't replicate in --mus. It only happens in --mash.

Experiment A:

1) Start chrome with --mash.
2) Ensure that the bookmark bar is shown on the new tab page.
3) Mouse over the part of the tabstrip with tabs / the new tab button. Notice
that the events get dispatched correctly.
4) Very slowly mouse down pixel by pixel to the middle of the omnibox. Notice
that there's a few pixels where the mouse pointer will get dispatched to the
omnibox (and change the cursor to the i-beam) before being dispatched to the
web page underneath!
5) The area where events are dispatched to the top of the BrowserFrame are
exactly the size of the Bookmarks Bar sitting under the BrowserFrame.

Experiment B:

1) Start chrome with --mash.
2) Ensure the bookmark bar is *not* shown on the new tab page.
3) Notice that all events in the client area are dispatched to the underlying
webpage.

OK, but why is the above happening? Well, //services/ui/ws/window_finder.cc:
FindDeepestVisibleWindowForLocation() is selecting the underlying web contents
for dispatch. My current theory about *why* it's selecting the webcontents is
because it is trying to find the deepest window which is within the bounds.

sky@ commented that this might be related to how the overlay that we build in
mash (see //c/b/u/v/f/immersive_mode_controller_ash.cc: CreateMashRevealWidget())
and how its layers are painting from a different window.