ellyjones@ might have an idea of where the code is that is supposed to make these things line up.

tapted has worked on this a bunch.

*ping*

It's in my queue (it's a big queue).

The fix is probably similar to  Issue 690361  if you want to take it.

Yeah, I can do this.

Should the arrow point to the center of the search icon? Or the middle of the bottom edge?

After further archaeology, there is this old comment in LocationBarViewMac:

https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/location_bar/location_bar_view_mac.mm?l=654

The comment says that the First Run bubble's left edge is supposed to align with the omnibox's left edge, which is what it is currently doing. That code turns out to date to  issue 60576 , but I don't see any particular UI decision about it in https://codereview.chromium.org/4544004, so I'm fine with breaking that alignment now.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b1cf560ccc8850e6fd059c3f32cde1a88787537b

commit b1cf560ccc8850e6fd059c3f32cde1a88787537b
Author: ellyjones <ellyjones@chromium.org>
Date: Wed May 17 19:38:13 2017

cocoa: move first run bubble's arrow

Right now, the left edge of the bubble lines up with the left edge of the
omnibox, but that leaves the arrow pointing at nothing. Move the bubble so the
arrow points at the location icon.

BUG= 719117 

Review-Url: https://codereview.chromium.org/2890863002
Cr-Commit-Position: refs/heads/master@{#472537}

[modify] https://crrev.com/b1cf560ccc8850e6fd059c3f32cde1a88787537b/chrome/browser/ui/cocoa/location_bar/location_bar_view_mac.mm

Looks much better! :-)

However, I noticed that the pointer height is not the same as for permissions. I'll file a separate bug.

Deleted: Screen Shot 2017-05-23 at 13.33.52.png 324 KB

	Screen Shot 2017-05-23 at 13.33.52.png 324 KB View Download

ellyjones: It seems the pointer is still not centered, which is especially visible if the icon is not the search icon. Would you be able to tweak it some more? (Or triage to something lower priority/mark as available.)

Deleted: Screen Shot 2017-05-30 at 15.07.05.png 716 KB

	Screen Shot 2017-05-30 at 15.07.05.png 716 KB View Download

That dialog should never appear on stackoverflow.... (how did you get that? is it a bug?)

It should only appear while the new tab page is showing, and the icon is a magnifying glass. Then, it might be look more sensible - the magnifying glass doesn't have a definite "center".

> how did you get that? is it a bug?)

This happens every single time you open Chrome with a new user data dir if you don't pass --no-first-run. (Which I currently don't, because I want to avoid passing unnecessary flags, and catch UI/security issues during first run..)

For users, it should start on a new tab page, with the search icon. The anchoring looks OK there; with the magnifying glass (imo).

I think -- only in Canary (for Mac) -- there's an experiment to start on chrome://welcome instead, and that bubble should appear only after opening a new tab page, signing in, or clicking "no thank you".

If a user ignores the welcome page, doesn't open a new tab, and instead types in a URL or search, then the anchoring will be off. I think that's the remaining bug here.

See Issue 658434 - I'm not sure what the plan for chrome://welcome is on Mac. ewald@ or tmartino@ might know. My dev channel doesn't show it on first run.

Deleted: Screen Shot 2017-05-31 at 10.18.54 am.png 52.6 KB

	Screen Shot 2017-05-31 at 10.18.54 am.png 52.6 KB View Download

lgarron: the icon being off center is deliberate: https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/location_bar/location_bar_view_mac.mm?l=655

It should not show up when there isn't a magnifying glass, so as #14 said I think that is the real bug here.

chrome://welcome should definitely be appearing on Mac on all channels.

The --force-first-run flag won't necessarily trigger it; it's shown once per-profile, so if you don't delete your profile between tests it won't appear. If you're not observing that behavior on Dev, then please let me know. It could be related to crbug.com/690603

tapted@ - are you clearing your user data dir between Dev channel first runs?

#c17: yup

$ rm -r /Users/tapted/udd20170531
$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=/Users/tapted/udd20170531

Turns out this is the Google-installed '/Library/Google/Google Chrome Master Preferences':

{
  ...
  "distribution": {
    "skip_first_run_ui": true,
    "show_welcome_page": false,


renaming that file gives me chrome://welcome

Google is suppressing the welcome page...? That's...odd. Does anyone know who controls the Google-installed Master Prefs file?

Anyways, thank you for verifying that's Googler-specific and not what the general public would see. It's worth verifying that the DSE bubble works as expected on the chrome://welcome page, since that's what the majority of the population will see. As Trent mentioned, we expect it to not be shown on chrome://welcome, and instead be shown when the user opens another tab or navigates to the NTP.

> Does anyone know who controls the Google-installed Master Prefs file?

master file appears to live at go/zsxzi

> we expect it to not be shown on chrome://welcome, and instead be shown when the user opens another tab or navigates to the NTP.

Suppression of the bubble on chrome://welcome happened in r449119 (for  Issue 689888 ). I observed in  http://crbug.com/690361#c9  that it had gaps. It sounds like rather than suppressing on chrome://welcome the bubble should be *restricted* to chrome://newtab only.

I'll reach out to macops-team@ about the master prefs file.

Hmmm, interesting. Would that imply that if the user never opened a new tab and simply did their browsing within the tab that gets created on first run, they'd never see the DSE bubble? Do we know whether that's okay from a legal standpoint?

We are talking about the bubble that points at the omnibox and says "You can search from here", right?

Yes, and provides an opportunity to change your default search engine.

I believe this bug is currently fixed. In re #20, if we want to change that restriction, that should be a separate bug.