Fix hittesting in the OpaqueBrowserFrameView for frames without a tabstrip. The HitTest() functi...

Fix hittesting in the OpaqueBrowserFrameView for frames without a tabstrip.  The HitTest() function was using GetBoundsForTabstrip(), which returns the ideal tabstrip bounds assuming a tabstrip were visible, instead of the actual tabstrip bounds.

Also cleans up some unnecessarily verbose code.

BUG=82524
TEST=Install a Chrome theme.  Visit http://www.liveatc.net/search/?icao=ath and click the green "listen" button that "requires Java".  A popup window with an infobar should appear.  The infobar buttons should be clickable.
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=86845

[Peter Kasting, 2011-05-26 01:13:58]

I'm not sure I understand exactly what your original change to HitTest() in
http://codereview.chromium.org/6692001/diff/20001/chrome/browser/ui/views/fra...
was trying to accomplish.  If all you wanted to do was make hittesting not deref
NULL when the BrowserView had no tabstrip, then this change should preserve
that.  Otherwise, I may have functionally affected you.  Please ensure this
doesn't break your UI.

By the way, the approach you implemented in that series of patches of having a
NULL tabstrip (and other frame components) is the wrong approach.  You should
change to the method that the browser was using for other tabstrip-less windows,
which is to have non-NULL frame elements that have zero size.  This means you
can rip out all the NULL checks you added and is much more convenient for
various bits of positioning code.

Making this change myself is beyond the scope of this patch, but please do make
it.

[rharrison, 2011-05-26 13:58:11]

On 2011/05/26 01:13:58, Peter Kasting wrote:
> I'm not sure I understand exactly what your original change to HitTest() in
>
http://codereview.chromium.org/6692001/diff/20001/chrome/browser/ui/views/fra...
> was trying to accomplish.  If all you wanted to do was make hittesting not
deref
> NULL when the BrowserView had no tabstrip, then this change should preserve
> that.  Otherwise, I may have functionally affected you.  Please ensure this
> doesn't break your UI.
> 
> By the way, the approach you implemented in that series of patches of having a
> NULL tabstrip (and other frame components) is the wrong approach.  You should
> change to the method that the browser was using for other tabstrip-less
windows,
> which is to have non-NULL frame elements that have zero size.  This means you
> can rip out all the NULL checks you added and is much more convenient for
> various bits of positioning code.
> 
> Making this change myself is beyond the scope of this patch, but please do
make
> it.

Your changes LGTM.

My changes were legacy from an approach to the WebUI login that I was
attempting. I have obviously missed removing some of it. I will need to go
through my CLs and make sure that I have reverted all of the changes that I
made. Thank you for catching this.