The cancel icon shouldn't flash on. 
Could the refresh icon remain still?

Assigning to Patrick for NTP triaging help (though don't know if this is a desktop or an NTP issue)

Note that this sort of stuttering can happen when loading almost any website, depending on what the website does.  We should consider whether a combination of fixes is needed here, e.g. change how the NTP is implemented to not do this, and/or coalesce updates to toolbar state more aggressively.

I think we already coalesce things like tab title changes, maybe the issue is just that we're not coalescing stop/reload changes enough.

tschumann@ for triage help while nepper@ is OOO

re: #4
I notice that for the other Chrome-owned destinations (bookmarks, history, downloads, etc.) it looks like that coalescing  is working well so there's something funny happening with NTP in particular. That's sad because it's the most visible one :/ 

re: #1
It sounds like helenepark@'s idea is to keep the reload icon permanently (never showing stop) when we're opening the NTP. I could imagine extending that to all of our local Chrome-owned UIs. stop-then-reload is most useful for network problems and we shouldn't have those so the flashing icon state is noise we could avoid. 

it seems the underlying reason is that the standard new-tab page is being loaded remotely from GWS. It's a pretty fast load but data is being fetched and hence the behavior of the reload/cancel icon. 

other assets like bookmarks, history, downloads, etc. are completely local and don't require a load -- hence no stuttering.
I didn't look into the code, but I'd guess the button is triggered by an actual network fetch being done and I'd like to avoid adding more special cases leaking new-tab-page code in more places. That said -- what if there's a network problem?

The good news is: we also have a local NTP (chrome-search://local-ntp/local-ntp.html) which does not have this behavior. Just open it and compare the "reload" behavior to the remote (standard) NTP.

Even better news is that Marc is working on migrating to the local NTP which should solve this problem on a higher level.

Making the NTP local seems like the cleanest way to go, however I'm not sure if any progress is being made on that (Issue 583289 was opened 1yr ago to track it). If making the NTP local is our preferred fix we need to work on getting that change to happen.

the bug has been sitting for a while indeed, but it's a priority for treib@ this quarter.
Marc can give an update on tentative ETAs.

That said, we (Zine NTP team) won't have any cycles for a specific work around this quarter. We prioritized other PE NTP  issues [e.g. local NTP for latencies, unreliable icons for NTP tiles] for this quarter already.

The local NTP work is tracked in crbug/583289
The launch is targeting M65.

Marking this one as won't fix.

Hello tschumann@, is the reload/stop jank during New Tab creation for the localNTP tracked in another bug report, so that I can star it? I can't find a report reflecting this issue in the list of the blocking issues of bug 583289.

Thank you in advance.