Mac: Give bubble windows an initial position before showing them.

Mac: Give bubble windows an initial position before showing them.

Otherwise initialization that occurs offscreen can load incorrect screen
metric information. E.g. a RenderView will assume it is on the primary
display when loaded in a bubble, which results in it being created with
an incorrect scale factor in some screen setups.

This CL adds a call to -[BaseBubbleController setAnchorPosition] in the
non-NIB initializer to give the window a good estimate of the position
it will eventually be shown at.

BUG=324748
Committed: https://crrev.com/41a9426745a734139f7d8442a83efe2153e63516
Cr-Commit-Position: refs/heads/master@{#295625}

[tapted, 2014-09-17 02:37:16]

tapted@chromium.org changed reviewers:
+ rsesek@chromium.org

[tapted, 2014-09-17 02:59:39]

Hi Robert, please take a look. I can think of a few alternative fixes (see e.g.
notes in patchset 1/extension_popup_controller.mm).

Tackling it at this level seems right, since the BaseBubbleController
initializer already knows the parent window and anchor. However, it's not
attempting to guarantee the exact position it will eventually be shown at. For
example, while changing the anchor point (between init and show) will call
updateOriginFromAnchor, changing the alignment or arrow position will not. But
for a transient bubble I don't think there's benefit adding more logic for that.

(note GetWebScreenInfo(NSView* view) in render_widget_host_view_mac is where it
was reading an incorrect window position.)

[Robert Sesek, 2014-09-17 16:52:48]

Yes, I think it's reasonable to handle this here.

https://codereview.chromium.org/573143002/diff/1/chrome/browser/ui/cocoa/base...
File chrome/browser/ui/cocoa/base_bubble_controller.mm (right):

https://codereview.chromium.org/573143002/diff/1/chrome/browser/ui/cocoa/base...
chrome/browser/ui/cocoa/base_bubble_controller.mm:89: [self
updateOriginFromAnchor];
Why not do [self setAnchorPoint:] instead?

[tapted, 2014-09-18 02:58:22]

https://codereview.chromium.org/573143002/diff/1/chrome/browser/ui/cocoa/base...
File chrome/browser/ui/cocoa/base_bubble_controller.mm (right):

https://codereview.chromium.org/573143002/diff/1/chrome/browser/ui/cocoa/base...
chrome/browser/ui/cocoa/base_bubble_controller.mm:89: [self
updateOriginFromAnchor];
On 2014/09/17 16:52:48, rsesek wrote:
> Why not do [self setAnchorPoint:] instead?

Done.

The nib codepaths complicate things a bit -- updateOriginFromAnchor needs to
happen after awakeFromNib (it sets the arrow location on InfoBubbleView which is
an IBOutlet), which is why they're ordered like this in showWindow as well (and
why we can't just move that setArrowLocation to the initializers)

But nothing leading up to the end of awakeFromNib relies on the anchor_, so
setAnchorPoint here works too.

[Robert Sesek, 2014-09-18 14:45:31]

LGTM

[tapted, 2014-09-18 23:05:46]

The CQ bit was checked by tapted@chromium.org

[tapted, 2014-09-18 23:06:10]

The CQ bit was unchecked by tapted@chromium.org

[tapted, 2014-09-18 23:06:28]

The CQ bit was checked by tapted@chromium.org

[commit-bot: I haz the power, 2014-09-18 23:09:15]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/573143002/60001

[commit-bot: I haz the power, 2014-09-19 00:35:34]

Committed patchset #4 (id:60001) as a169e1237ab2527043b09f68a3d001f2d39ac9f7

[commit-bot: I haz the power, 2014-09-19 00:36:18]

Patchset 4 (id:??) landed as
https://crrev.com/41a9426745a734139f7d8442a83efe2153e63516
Cr-Commit-Position: refs/heads/master@{#295625}