Disable Views fuzzing with --disable-views-rect-based-targeting.

Disable Views fuzzing with --disable-views-rect-based-targeting.

The new Views hit-test-rect fuzzing feature is buggy.
(r232797 caused tab close button breakage in Issue 332334)
Let --disable-views-rect-based-targeting toggle that code.
(affected users can workaround defects with that flag)
This might be a merge candidate for M-33 and M-32 branches.

BUG=332334, 129794, 306186
R=sadrul@chromium.org,sky@chromium.org
TBR=tdanderson@chromium.org
TEST=Clicking the tab close button works with Tahoma 17+ and other large MessageBox fonts used for Chrome UI when users supply the "--disable-views-rect-based-targeting" commandline flag. That disables "Views Fuzzing", but touch-based interaction should still work reasonably enough.

[msw, 2014-01-22 00:08:42]

Hey Sadrul, Scott, and Terry; please take a look.

[sky, 2014-01-22 01:18:16]

We shouldn't need to change this override. We should disable views fuzzing if
this is important. I don't know why disabling doesn't really disable it, that'll
obviously need to be looked at.

[msw, 2014-01-23 00:28:16]

The latest patch set allows users to disable views fuzzing with
--disable-views-rect-based-targeting, but otherwise leaves the feature enabled
and unchanged. This should let users affected by Issue 332334 workaround the
defect without impacting the general user-base. This might be a good workaround
for merging to M-32, but Shrikant also has a WIP layout fix. Please take a look.

[sadrul, 2014-01-23 00:40:42]

https://codereview.chromium.org/143803010/diff/1/chrome/browser/ui/views/tabs...
File chrome/browser/ui/views/tabs/tab.cc (right):

https://codereview.chromium.org/143803010/diff/1/chrome/browser/ui/views/tabs...
chrome/browser/ui/views/tabs/tab.cc:409: return false;
Do this only for defined(OS_WIN)?

https://codereview.chromium.org/143803010/diff/130001/ui/views/view.cc
File ui/views/view.cc (right):

https://codereview.chromium.org/143803010/diff/130001/ui/views/view.cc#newcod...
ui/views/view.cc:953: if (views::switches::IsRectBasedTargetingEnabled() &&
HasHitTestMask()) {
Does this break hit-testing along the slanted edges of the tabs?

[msw, 2014-01-23 00:54:32]

https://codereview.chromium.org/143803010/diff/1/chrome/browser/ui/views/tabs...
File chrome/browser/ui/views/tabs/tab.cc (right):

https://codereview.chromium.org/143803010/diff/1/chrome/browser/ui/views/tabs...
chrome/browser/ui/views/tabs/tab.cc:409: return false;
On 2014/01/23 00:40:42, sadrul wrote:
> Do this only for defined(OS_WIN)?

Moot.

https://codereview.chromium.org/143803010/diff/130001/ui/views/view.cc
File ui/views/view.cc (right):

https://codereview.chromium.org/143803010/diff/130001/ui/views/view.cc#newcod...
ui/views/view.cc:953: if (views::switches::IsRectBasedTargetingEnabled() &&
HasHitTestMask()) {
On 2014/01/23 00:40:42, sadrul wrote:
> Does this break hit-testing along the slanted edges of the tabs?

Hmm, yeah. Adjacent tabs obscure the right half of the (x) button's hit test
rect. So --disable-views-rect-based-targeting makes only the left half
responsive to hover/click, even with normal sized system fonts. That's not good,
but still better for users that can't click the (x) button at all. Shrikant's
layout/mask will be better for the long term, but this is still a potentially
viable way to help M-32 users suffering from Issue 332334. I'm open to
alternate/additional fix ideas.

[sky, 2014-01-23 16:40:04]

I have a better fix for this here: https://codereview.chromium.org/134203004/ .
It's not perfect, but hopefully good enough to merge.

[msw, 2014-01-23 17:59:36]

On 2014/01/23 16:40:04, sky wrote:
> I have a better fix for this here: https://codereview.chromium.org/134203004/
.
> It's not perfect, but hopefully good enough to merge.

Okay, I've closed this CL, we'll go with your fix.