[OSX] Use view coordinate system for tracking rect

[OSX] Use view coordinate system for tracking rect

No observable effects, but NSTrackingArea needs coordinates in the view's reference frame, not the superview's. 

No unit test since I couldn't synthesize proper mouse events
for NSTrackingRect.
(See also https://codereview.chromium.org/12330108, same problem)

R=thakis@chromium.org
BUG=none

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=201954

[Nico, 2013-05-23 04:53:38]

This has no BUG=, no unit test, and no TEST= line. What's the observable effect
of this change?

[groby-ooo-7-16, 2013-05-23 06:08:56]

Clarified description.

Observable effect: BaseViews that have a frame origin that is not (0,0) have a
proper tracking rect after this change. There are no views like that in Chrome
so far, as I can tell - this is prep for a not-yet-ready CL.

Unit test: As I said in the original message, it seems impossible to write a
unit test for NSTrackingRect. See also the mentioned CL, where you ran into the
same issue.

Test instructions: None, since there is no way to manually test this.

Bug: None, since this is a trivial code cleanup.

[Nico, 2013-05-23 15:16:54]

On 2013/05/23 06:08:56, groby wrote:
> Clarified description.

lgtm, thanks

> 
> Observable effect: BaseViews that have a frame origin that is not (0,0) have a
> proper tracking rect after this change. There are no views like that in Chrome
> so far, as I can tell

Maybe the web contents area when the download shelf is open? Does this CL change
anything in that case? (see TEST= line in the cl description you linked to for
how to check)

> - this is prep for a not-yet-ready CL.
> 
> Unit test: As I said in the original message, it seems impossible to write a
> unit test for NSTrackingRect. See also the mentioned CL, where you ran into
the
> same issue.

Understood. My point was that it's difficult to tell why a CL was landed months
down the road if the CL description doesn't say why the change was made in some
form.

> 
> Test instructions: None, since there is no way to manually test this.
> 
> Bug: None, since this is a trivial code cleanup.

[groby-ooo-7-16, 2013-05-23 20:07:03]

>  Maybe the web contents area when the download shelf is open? Does this CL
> change
> anything in that case? (see TEST= line in the cl description you linked to
> for
> how to check)


Not affected, as far as I can tell. (Original page is gone, recreated as
http://jsfiddle.net/aMxeW/)



> Understood. My point was that it's difficult to tell why a CL was landed
> months
> down the road if the CL description doesn't say why the change was made in
> some
> form.


Yes, I realized I was a bit terse when I read your reaction :) Thanks for
pointing it out!

[commit-bot: I haz the power, 2013-05-23 20:15:27]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/groby@chromium.org/15797002/1

[commit-bot: I haz the power, 2013-05-23 22:06:43]

Retried try job too often on linux_chromeos for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...

[commit-bot: I haz the power, 2013-05-24 00:45:32]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/groby@chromium.org/15797002/1

[commit-bot: I haz the power, 2013-05-24 01:26:03]

Change committed as 201954