rjc.personal@ if possible can you please provide a reduced test page for faster triage .

Sure, here's a very simple example:
http://mmm.wallstreethorizon.com/iframe_test.asp

The source is in the attached ZIP file
re
-rich

Deleted: iframe_example.zip 1.3 KB

iframe_example.zip 1.3 KB Download

Bisect info: 486847 (good) - 486855 (bad)
https://chromium.googlesource.com/chromium/src/+log/defd8d7a..661ee909?pretty=fuller
Suspecting r486854 "Change meaning of "IsLoadingToDifferentDocument" in WebContents to only"
Landed in 61.0.3158.0

Quoting r486854:
>throbber won't flicker when content is loaded in an iframe right after the main frame finishes loading

However, now the throbber isn't animated even when an iframe is reloaded long after the main page has finished loading, which is not what was intended, apparently.

:)
I didn't know it was called a "throbber".

Personally, we prefer to see the throbber even if it flickers with the favicon. What happens now is that the user has been trained to watch this while waiting for page completion and gets confused, feeling that their computer has frozen because there is no indication of activity. 

We have tested in Firefox and it operates fine (the throbber/spinner/doohicky appears during a right hand frame refresh.

I think we did some intentional changes in this area, though I'm failing to find the CLs in question. japhet, do you remember which CLs?

estade@ changed this in https://chromium-review.googlesource.com/c/chromium/src/+/569060.

There are some pages that work less well with this change unfortunately, but we believe that on the whole this is an improvement for more pages than it breaks. For what it's worth, Safari also does not show a loading indicator in these cases, so sites that don't show their own loading indicator for iframe loads will have the same problem there.

We've talked about providing some web developer control over the browser's progress bar / spinner before. Perhaps we should resurrect those discussions. +kenji/rbyers I vaguely recall the two of you mentioning this?

re #7, #8. Not sure why r486854 making the throbber flip less often is an improvement. I've been using the web for 10+ years and I don't even remember noticing that animation. Was there really a problem worth breaking any site's UX at all even as minor as the reported one? 

Not having a visual indicator for a manual refresh performed long after the page has finished loading seems an obvious deficiency, especially considering the longstanding historical behavior in Chrome. However, there might be a better solution: for example, Firefox only changes the toolbar button from Refresh icon to Stop icon when I manually reload an iframe.

I totally appreciate that it's very frustrating to have this change out from under you. Hopefully we'll be able to prioritize some web developer control over this behavior sooner rather than later.

The flicker is the most minor issue with the previous behavior in my opinion. 

We've found that hiding the favicon while the spinner is going makes for a bad user experience in general because people use the favicon more than the tab title for remembering which tab is which, particularly when they have many tabs open.

Also, sites use iframes for many async loading cases things these days, so they get the spinner in cases that confuse users or lead to very long-lasting or distracting spinners. We've had many reports of site authors going through complex contortions to avoid showing the spinner when async loading iframe content.

So, in all it's a mixed bag. It's not ideal for sure, but we think it's net positive.

For what it's worth, we are also exploring changes to when the spinner finishes for top-level pages to better match timing that we think is most useful to users, i.e. when does the page have most of it's useful content painted rather than the current behavior tied to the onload event (which comes way too late on some pages and comes while the page is still totally white on others).

#10, makes perfect sense now.
So what about the Firefox solution? Only flip the Refresh icon to a Stop icon on user gesture. Like maybe after 500ms.

Disconnecting the timing of the reload/stop change from the spinner seems plausible to me. I don't quite understand your description of the Firefox behavior though. What do you mean by manually reloading an iframe?

I think my preferred behavior would be to get rid of the stop button entirely and only have the reload button. I question how much value the stop button really provides.

#12, using http://mmm.wallstreethorizon.com/iframe_test.asp from #4, open that page in Firefox, wait for it to load (5 seconds), right-click the iframe, click "This frame", click "Reload". Favicon doesn't show the spinner, only the Reload button in the toolbar changes its icon to the Stop icon. Chrome 61+ after r486854, on the other hand, doesn't indicate anything for this sequence of actions.

#8,#10, I understand, Iframes and asynchronous processing make the concept of "busy" and "done" a hard one to determine for an entire page. I'm sorry, but I don't see the need to prioritize the favicon over some sort of "loading" affordance. It seems like there could have been multiple options (in order of preference):

1. Show both the throbber and the favicon (similar to how we now see both the favicon and the sound icon)
2. Use another approach to showing "doneness" -- make the tab throb or fade or gray or some other visual difference, while preserving the favicon. 
3. Make the throbber show only on the currently selected page (the one you are one, that way you can easily navigate to the other tabs using the FAVICON. If they are still loading, change to thobber when selected.)
4. If there is no favicon, only show the throbber (minimal sitedesigner control over the feature)
5. Provide a settable option, set it to "no throbber for Iframes" but allow the user to override this
6. Provide some way for the site to set an "I need the throbber" flag

Just breaking what has been a  useful feature that people have relied on for a minor aesthetic seems like a bad decision.

From our organizations standpoint, given that there is a wait/busy state anywhere on the page it makes more sense to show the throbber than to hide it. 

At this point we are seriously looking at changing to Firefox because this issue is so annoying to our users.

Ojan seems to have a better grasp of all the implications on both sides of the argument than do I, so assigning to him. I agree with most of what he said, although I will say the flicker was indeed a highly motivating factor for me (and Alex Ainslie, who pointed it out).

Manually reloading an iframe seems very much like a minority use case in comparison to the frequency with which this change improves the experience on normal navigation.

> I think my preferred behavior would be to get rid of the stop button entirely and only have the reload button. I question how much value the stop button really provides.

I think the value is that when you press refresh, it gives you visual feedback that your click did something. But I don't think I use it much and not sure how much others do so I wouldn't argue for its continued existence.

Apparently, the most significant use case improved by r486854 is embedded youtube videos (and similar). Gotta agree this use case is indeed thousands times more popular than iframe/frameset used to present site's own content.

Unfortunately, it doesn't look like we'll be able to work on an API for developers to control the spinner in the near future. I would like to see us ship it, but it will take some significant design and spec work because it needs to work well for all the different UI treatments browsers give to this (spinners, progress bars, etc). kenjibaheux@, do you have a bug for that we can point people to so they can follow along when we do actually start working on it?

As per my earlier comments, we were aware some sites work better with the old behavior, but believe there's considerably more content that works better with the new behavior. Some of the evidence that this doesn't break a lot of the web is that Safari already ships this behavior (and we don't hear outcry) and that we haven't gotten many bug reports (this is the only one I know of).

We'll reconsider of course if we get new data indicating significantly more breakage or user frustration than we expected.

Sorry, I know that's a frustrating answer.

Actually, I'll make this be the bug for adding the developer control. kenjibaheux, please dupe this if there's already an existing one.

This is P3 for now since we don't hear a lot of developer demand for this, but if we do hear from many developers that they want this (e.g. by starring this bug) then we'll reconsider the priority next time we review the top starred feature requests.

Sounds good, I'm not aware of any existing crbug for this feature.

I would recommend opening a thread on https://discource.wicg.io to share and discuss motivating use cases. 

I'm guessing that some of the use cases would be better served by a custom and local UX treatment (i.e. a loading UI for the particular iframe/object of interest) rather than driving Chrome's progress bar. There could be gaps in the web platform though ([1]). The more concrete the use cases, the better.

[1]: perhaps a "progress" extension to the Signal concept introduced for aborting fetches?. See https://developers.google.com/web/updates/2017/09/abortable-fetch

If tab icon flickers for pages that have embeded videos ..ok, fine - I can understand that this is the major use case that triggered this change. However this behaviour was around for years and some users got used to it. It's not nice to remove it like that. Why not put throbber or some sort of activity indicator APART from that icon, or animate the tab text, or put a sort of progress bar on the bottom of the tab label?

#4 is my exact use case. In our web app (used by over 10,000 customers) we have a top frame and a left navigation frame. When clicking a link in the main window it loads a new page in the main window while leaving the top and left pages/content the same. There is now no indication that the page is loading.

In the case of slow loading or non-responding pages this lack of visual indication is confusing to our users. Since there is no spinner/throbber they think that nothing is happening, when in fact the page is waiting to finish processing or displaying.

This might not seem like a big deal to the Chromium Developers, but it IS a big deal in our app.

I am also seeing this problem. I load pages in iframe based a list of links provided to my users. When the links are clicked, the user gets no feed back that anything is going on until the iframe is reloaded. The busy cursor needs to come back when an iframe is loading in the page.

I don't understand the "developer control" part... A loading page triggers the loader, right? Like it does when the frame loads for the first time. That's how browser UI works... Is this really a feature?

 Issue 780234  has been merged into this issue.

#24 The Chromium developers are making us turn this into a "feature". If the page is not done loading, even the frames, the spinner should spin (or the throbber should throb). Just because because people like inserting youtube videos onto their pages it does not mean Chrome's behavior should change. If the page is not ready, spin the spinner. If the Chrome developers insist on alternate behaviors, like Chrome 61, then allow web developers to decide when their pages are loaded. Firefox does it right, the excuse that Safari is broken as well holds no water. 

I second the notion that this is unwanted behavior. For single page applications (not necessary web pages), the spinner is extremely useful when loading information in iframes, etc.

I am facing the same issue. I am working all day long with ServiceNow (for those who know this application) and, since Chrome 61, the loading spinner no longer shows up when you click on a link in the tool. This is very frustrating, since it was extremely useful to know whether the page was actually loading or not. Please consider bringing back this feature. Thanks in advance.