To reproduce it easily, this method can be modified and always return YES:
+[SigninPromoViewController shouldBePresentedForBrowserState:]

Hello Elias,

I noticed there are some metrics for the first run promo (really on the first time) that doesn't exist on the promo on the second time.

Do we want to have the exact same metrics? I would guess so.

What do you think?

Do we have a bug for unity yet?

I should put this bug blocked by unity. I'm not sure it is relevant to fix that bug before unity.

Having a different string for the cancel button: a) "NO THANKS" in FRE and b) "CANCEL" in SSOPromo was a deliberate choice done by PM/UX.

So for me this bug is actually WAI.

That doesn't make sense to tap on "Cancel" when no action has been asked by the user. Cancel should only be done when an action has been started, but in that case, the user did nothing, so for the point of view of the user, there is nothing to cancel.

The button should read "NO THANKS" instead of "CANCEL" when we present the sign-in promo post-first-run. I don't think this needs to be blocked on the Unity work; we should just make this quick fix with today's designs, and we'll make sure to incorporate this into our Unity specs as well.

Jerome, which metrics are you referring to? We do have metrics for the periodic sign-in promo (Signin.SigninStartedAccessPoint.[Signin promo], etc.)

Yes, if I'm not mistaken, this only used when starting Chrome for the first time. When the first run sign-in promo is shown again, this metrics doesn't seem to be recorded.

Hmmm, I don't think that's true. Are you sure about that? The ".[Signin promo]" bucket for the Started and Completed histograms both look like it's only being recorded post-first-run to me.

To be clear, desired behavior is:

- Signin.Signin[Started|Completed]AccessPoint.[Start page] is recorded on first run
- Signin.Signin[Started|Completed]AccessPoint.[Signin promo] is recorded the next time the promo is shown, sometime after first run

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Moving this back to Assigned. My question about metrics in #9 remains.

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I don't know why I said #c8. But I definitely see the metrics being recorded as ACCESS_POINT_SIGNIN_PROMO.

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot