The one very nice thing about this is that it shows when we're hanging on an extension, and it says which extension it is.  I agree that the others aren't too useful to the average end user.

+1 to mmenke@'s point.  This is pretty invaluable if you have a poorly-written extension.  (It's also useful to see other "hang" points, and I find it helpful to see if anything is advancing, etc.)

I'd prefer we don't get rid of these entirely.  I'd be open to changing wording, eliminating some of them, etc, but I think they are useful in some cases.

Sending to markchang@ for assessment.

At the moment, these messages serve as useful things to aid in any long-running or semi-broken state. I think until we have a better surface for that, or a UX pattern to call out this information, this status message should stay.

Can we move those messages into devtools, then? I haven't heard a single use case that matters to non-developers. (I doubt even the extension one is useful outside of devs/power users, but we could certainly highlight hanging extensions in better ways - i.e. with an uninstall button in the toolbar :)

These messages are already available in the network panel of devtools, and with a far more advanced interface (including logging) in chrome://net-internals/
It's line noise in the status bar, so better to kill it.

We expose what extension is blocking network requests in devtools?  Even with the network service enabled?  Note that with the network service enabled, net-internals doesn't show blocking extensions, at least.

Use cases that I use this for with just about every page I view in Chrome, as a user:
* on hover, where will this link really take me (especially mailto: links.. I hate those)
* every long POST operation, making sure the upload is actually going
* it's my blinkenlights for every page load -- are things still working? 
* it's my blinkenlights for when pages feel like they are just stuck loading -- who is to blame?
* for pages that don't trigger a page loading indicator but have tons of ajax-y stuff (messenger.com), that's my loading indicator

...

Of course, that's N=1 for data. If we want to clean up the cruft there, then I'd advocate for a Mac-like approach (at least on that platform) to allow users to show/hide the status bar. This is what Safari (and many Apple apps like Finder) do.

Markchang:  Note that the hover information comes from elsewhere.  The other cases you mention are all relevant here, though.

Are they not in chrome://net-internals/ ? Either way, keeping this aspect would necessitate doing the same work once we switch to the network process, so it's not an argument to keep it as is.

mmenke@: got it. I don't know what codepaths trigger this, but I was mostly talking about what I use that UI surface for. So, code orthogonal, yes.

With the network service enabled, extensions are not hooked up to the network stack.  It's not an argument for keeping it as-is, it is an argument for doing something (In the same way that "It's in devtools" would otherwise be an argument for doing nothing).

markchang@ - The proposal is *not* to change window.status behavior (e.g. hover). Rather, the proposal is to move to a simplified message for load status, instead of spamming the status bar with the URL for every single resource load.

Hmm... Just my $0.02, but I don't actually think this is a power user feature (or very useful at all for any kind of net internals-like data).  It moves too fast to read in 99% of cases.  I think instead, the value is very much in the "blinkenlights" scenario that markchang@ describes - it's pretty much the only user-visible indication of whether or not "something" is happening.  If it stops blinking for a minute, something's wrong.  If it keeps blinking, something's happening.  We don't really have anything else like this - the spinner will keep spinning whether it's stalled on a single event or not.  It's entirely just anecdata, but the folks I've talked to all rely on the status indication for the same thing - knowing whether to wait or to kill the page and try again.

And, FWIW, it looks like users *do* find the status bar when something goes wrong - a quick Google search for "Waiting for adblock" shows a ton of results for users saying "I tried to visit a page, and it got stuck here at the bottom", and I don't know that all those users would know to check out chrome://net-internals.

Repeating this one more time: The proposal here is to simplify the load status strings by replacing them with strings that are easier for the user to understand. The bug description even provides examples of strings that could be used for the different states (e.g. "Waiting for hostname....", "Waiting for cache", etc.). The only user visible difference is that we would stop spamming a random list of URLs, and instead display these more easily understood strings. As a bonus, this might even get us a small performance win by eliminating a large volume of update messages and repaints (jam@ has early evidence of a 9% win on some loading metrics).

Right now, I don't see any good arguments against this proposal, I'm keeping the bug available and we'll see if someone wants to pick it up.

> Repeating this one more time: The proposal here is to simplify the load status strings by replacing them with strings that are easier for the user to understand. The bug description even provides examples of strings that could be used for the different states (e.g. "Waiting for hostname....", "Waiting for cache", etc.).

I interpreted it differently, as "let's remove the status bar".  The bug summary is "Remove the networking-status".

Description:
---
When a page is loading, we //should// a status bar on the bottom left with text like:
"Waiting for hostname....", "Waiting for cache", "Establishing secure connection", "Processing request", etc...

This seems kind of unnecessary since to most users it means nothing. We don't show it on mobile. Should we remove it?
---

I read that //should// as a typo of //show//, but perhaps it was supposed to be //should show//?  But the strings listed there are exactly the strings we show today...

jam@, can you clarify what the proposal was? :)

My original proposal was to remove the status text when loading. Personally I think it's not useful, in aggregate. I understand some users might like it, but similar to any extra UI complexity there could always be a small percent of users who want something.

I defer to UX for the final decision.

Ah, sorry, people on this bug aren't on the other thread that led to filing this bug (and I guess that's where the replacement strings were discussed). Sorry for adding some confusion and grabbing the wrong strings, but my interpretation of the thread that led to this bug being filed was that UX is supportive of providing a much simpler status bar indication of load state.