Change log URL :
https://chromium.googlesource.com/chromium/src/+log/58.0.3021.0..58.0.3023.0?pretty=fuller&n=10000

Note : Above issue is not reproducible on chromium builds, hence providing the suspect using Change log info.

Suspecting : r 452874 or 452938 ? from CL

@spqchan : Could you please look into the issue and if possible please help to assign it to concern owner.

Hi ellyjones@,

Can you triage and find an owner (or assign someone to triage)?

This sounds likely to be my https://chromium.googlesource.com/chromium/src/+/5a963036e01f36fef69a05accdf2725e631d0ed0.  I'll take a look.  I probably just need to merge something.

I reproduced this locally with 59.0.3061.0. There's no need for a fresh install, just --user-data-dir=/tmp/path/to/somewhere/new will do the trick. Most likely there are some hidden but focusable views in FirstRunDialog.

I also reproduced it with 59.0.3053.3 (current dev), 58.0.3029.41 (current beta), but not with 57.0.2987.133 (current stable). In fact, I don't see that dialog in M57 stable at all. I had an M56 stable earlier, and that one worked fine and did have the dialog.

The key view loop in the working version is: [x] Set Google Chrome as... -> [x] Help make Google Chrome better... -> Learn more -> Start Google Chrome, while in Canary it's: [x] Help make Google Chrome better... -> Learn more -> nothing -> nothing -> Learn more -> nothing -> nothing -> Learn more -> ...

I suspect the problem lies in [FirstRunDialogController show]? I do not see any likely culprit CLs inside the regression range and I can't think of any plausible related change.

I got this to happen in a chromium build by removing the #if defined(GOOGLE_CHROME_BUILD) in first_run_dialog.mm; will have a look and see if I can figure out a root cause.

Ah, okay, the key view loop is working fine, but the checkboxes and the button are not drawing their focus rings properly.

A friendly reminder that M58 Stable launch is coming soon! Your bug is labelled as Stable ReleaseBlock, please make sure to land the fix, verified in trunk and get it merged into the release branch ASAP.

A friendly reminder that M58 Stable is launch is coming soon (less than 2 weeks)! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Can we we target the fix before next Beta Release which would be the Pre-Stable candidate. If the bug is not critical, please feel to punt to next milestone.

FYI: RC cut @ 4.00 PM Monday 04/17.

Just a heads up since this is marked as RB-Stable - we are aiming to launch M58 early stable this Wednesday, RC cut today @ 5:00 PM PT or latest by tomorrow noon if all goes well. Can you please take a look at this urgently and confirm if it's still a blocker for M58?

Please target to have a fix in M59.

rsesek@, sdy@ and I have done a bunch of investigation. Here are our conclusions:

1) These controls are using automatic focus rings, supplied by Cocoa using NSAutomaticFocusRing.
2) The automatic focus rings default to animating themselves in, which is controlled by a userdefault: NSUseAnimatedFocusRing.
3) Changing this userdefault to NO causes the focus rings to appear (without animation), but it affects all of Chrome, and AppKit appears to cache the value we set it to the first time it is used, so there is no easy way to enable it for just the first-run dialog.
4) Setting the userdefault called NSDebugAutomaticFocusRing gives us a clue what is going on: we see "starting animation" but no progress markers and no log entry for the animation ending, either.
5) Being a nib has nothing to do with this bug; a pure Cocoa implementation of this dialog has the same problem.

Our best guess is that the root cause is invoking [NSApp runModalForWindow:] for this dialog, which prevents the timers needed to draw the animations from running. When [_NSAutomaticFocusRing showForView:] is entered, we're in NSModalPanelRunLoopMode, which is one of the common modes, so we do not know why the timer would not be running. Ultimately we are invoking base::RunLoop::Run() on the main runloop from inside PreMainMessageLoopRun(), which seems dubious to me. Further investigation of this might not be a good use of time.

With respect to the above comment, should we still consider this as as a blocker or can  the label be removed. Kindly suggest.

Thanks.!

shrike@: this is kind of bad-looking but we're also pretty stuck, what do you think about RBS?

Removing RBS.

Looking through the bisect change list my timer cl stood out:

commit	3a16446d4864b4ad7159df1534357c9cc8ab21d7	
author	shrike <shrike@chromium.org>	Fri Feb 24 17:05:19 2017
committer	Commit bot <commit-bot@chromium.org>	Fri Feb 24 17:05:19 2017
[Mac] Reduce timer CPU use in MessagePumpCFRunLoopBase.

Review-Url: https://codereview.chromium.org/2709813003

And in fact disabling it fixes the bug. Apparently my hack and the hack of showing this dialog before entering main.

I'm having a *** of a time getting this dialog to show. With Chrome on corp the dialog won't come up because of enterprise default browser settings. But even hacking on Chromium I'm not finding the right code to comment out/modify to force it to come up. So I don't know if this is still a problem or not.

If it's still a problem, fixing it involves disabling the timer optimization until after the first run dialog runs (or maybe easier, adding API to temporarily disable it).

You should be able to repro this on a chromium build with `--user-data-dir=/tmp/somewhere --force-first-run --force-first-run-dialog`. I don't think this is super high priority at the moment.