603777 - Show loading state in right side of location bar (à la link hover preview)

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect)

Description

[Dave Garrett]

(Mike Beltzner in bug 602964 comment #5)
> I'd suggest we display the new URL in
> the location bar immediately (reverting if the page load is cancelled, natch)
> and put the "Connecting..." over to the right where the link preview went. This
> puts it, conveniently, right beside the "Stop" button.

Strings for these states are being added in bug 603717.

This would serve as an improved replacement for the removed status bar text.

This would use the same or similar styling as the link hover preview, I assume?

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Yeah, that's the idea.

Comment 2

[alexander :surkov (:asurkov)]

Can we add progressbar instead (or together with text strings) to the right? This allows to resolve the bug 605409 what has negative impact on screen reader users. This could be a string when the browser is connecting (or undetermined progressbar) and determined progressbar when page is downloading.

Comment 3

[Dave Garrett]

In reply to comment 2 -> bug 605409 comment 6

We've switched back to throbbers instead of progress bars in part because there's no such thing as a progress bar for a web page. There's really no way to know how long until the server is going to be done sending things. The bars were largely placebos. See bug 602964.

Comment 6

[:Margaret Leibovic]

Attachment: patch

This patch seems to do the right thing, but I haven't tested it very thoroughly yet.

Comment 7

[Drew Willcoxon :adw]

Comment on attachment 494227 [details] [diff] [review]
patch

gURLBar.setOverLink implements its own delay internally, so you don't need the timer here, but maybe I'm missing its purpose?  I think all updateStatusField needs to do is what setOverLink does, i.e., if gURLBar exists then just call setOverLink with the text.

Also, the terminology is now all wrong: it's not an "over-link" anymore but "over-status" or something. :)

Comment 8

[:Margaret Leibovic]

Oh, I guess the motivation for the delay isn't documented in this bug. The idea is to only show the status text if it hasn't changed after a given period of time. This is a compromise that lets users know what's slowing down the browser without creating a lot of noise in the URL bar.

In bug 613390, Limi suggested a 3-5 second delay, but I found that 1 second seems to be a better delay period. This probably needs some testing to decide what's right.

Comment 9

[Drew Willcoxon :adw]

Comment on attachment 494227 [details] [diff] [review]
patch

OK.  This approach looks OK to me then.  setOverLink's internal timer is 1s, so you're actually delaying 2s.  Why clear the over-link first though?  Shouldn't it only change after the timer lapses?

Also, it seems like this could potentially interfere if the user is mousing over links in one doc while another is loading in a background tab and causing the status text to be updated.  One solution might be to do what the old status bar code did, which was (I think) to set a this.linkStatus or something in setOverLink and include that in the |text| calculation in updateStatusField as the first term.

Comment 10

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #9)
> Also, it seems like this could potentially interfere if the user is mousing
> over links in one doc while another is loading in a background tab and causing
> the status text to be updated.  One solution might be to do what the old status
> bar code did, which was (I think) to set a this.linkStatus or something in
> setOverLink and include that in the |text| calculation in updateStatusField as
> the first term.

If this means that the link is displayed, and the timer starts again (waiting 2 seconds) before it shows the "Waiting for…" text again, I agree. Or is this something else entirely? :)

Comment 11

[Matthew Turnbull [Bluefang]]

Attachment: example patch

IMHO there shouldn't be any delay. Users are used to what the status bar had, and that's what they expect (at least that's what I've gathered from my Status-4-Evar users). So if there is a delay to filter out information, I'd expect some users to complain about 'data loss'.

I think a delay would also make the behavior look inconsistent... sometimes showing connection information, and sometimes not. It could also erroneously suggest a problem for sites that load large content files (Flash objects, YouTube video, etc).

Also, it looks like there is competition between setOverLink() and updateStatusField() when 'busy'.

The example patch I've attached addresses these issues by:
1) Always updating the url bar
2) Persisting the overLink url and making setOverLink() use updateStatusField()
3) Giving overLink precedence and only show the status text when we're busy
4) Using a timer to clear the status text when we're no longer busy

I haven't actually tested this patch (and thus it being labeled an 'example'), but it's somewhat similar to what I've done in my Status-4-Evar extension.

Comment 12

[Dave Garrett]

(In reply to comment #11)
> IMHO there shouldn't be any delay. Users are used to what the status bar had,
> and that's what they expect (at least that's what I've gathered from my
> Status-4-Evar users). So if there is a delay to filter out information, I'd
> expect some users to complain about 'data loss'.

These are not the average user and thus not an example of what we want for the default. Power users often want more, but the other few hundred million Firefox users need simplification. We're aiming for a compromise here, and those who want more will simply use an extension to get more. (which is a good thing)

> I think a delay would also make the behavior look inconsistent... sometimes
> showing connection information, and sometimes not.

Honestly, connections and the Web in general are sometimes inconsistent, so I'd say it's fair for the status output to be so as well as long as it mirrors what is really going on. I would prefer it only tell me information I may care about rather than me having to filter through the noise myself.

> It could also erroneously suggest a problem for sites that load large
> content files (Flash objects, YouTube video, etc).

I wouldn't consider showing a message of some kind in this sort of instance an erroneous suggestion of a problem. If it's a big file, and it takes a while to download, that's worth mentioning as to why the page hasn't finished loading. It's not an error, per se, but it is a valid status that's more than just the par of quick page loading.

Comment 13

[Matthew Turnbull [Bluefang]]

(In reply to comment #12)
> These are not the average user and thus not an example of what we want for the
> default. Power users often want more, but the other few hundred million Firefox
> users need simplification. We're aiming for a compromise here, and those who
> want more will simply use an extension to get more. (which is a good thing)

The impression that I'm getting from S4E (5000+ users, reviews, support topic), firefox.uservoice.com, and Google searches, is that these are generally not power users, but regular users who are very unhappy with the removal of this information. IMHO biting the bullet and not compromising here would go a long way.

Also, AFAIK this text is available in most other browsers. Regardless of whether or not the information is useful, I think it's something people expect to be there (kind of like the lock icon).

> Honestly, connections and the Web in general are sometimes inconsistent, so I'd
> say it's fair for the status output to be so as well as long as it mirrors what
> is really going on. I would prefer it only tell me information I may care about
> rather than me having to filter through the noise myself.

At least always showing all network status messages is consistently inconsistent. If it wasn't for the fact that I know about this ahead of time, I would have been very confused as to why some network messages were being shown and others were not. I would have assumed it was a bug.



And another though just occurred to me. I know there has been a fair amount of effort into improving Firefox's perceived performance. However, I think spottily displaying information in a delayed manor would be counterproductive to that endeavor. If anything, I think the main reason I keep around the full status text is that it gives Firefox a much more snappy and responsive feel.

Comment 14

[Dave Garrett]

(In reply to comment #13)
We're getting a bit off topic about the demographics discussion, but all I'm trying to say is that extension and beta users are a tiny minority in comparison to the vastly larger number of Firefox users at large. (even the most used extensions can't get close to cracking past the single digits of a percentage of the total Firefox user base; anyone who even understands the word "beta" as applied here is an even smaller minority) We have to aim for the main base and then have extensions to customize for everyone who wants to.

WRT, most other browsers and expectations, I don't care. ;) We want to make what's best and sometimes that's copying someone else's good idea and sometimes that's doing things completely different.

> At least always showing all network status messages is consistently
> inconsistent. If it wasn't for the fact that I know about this ahead of time, I
> would have been very confused as to why some network messages were being shown
> and others were not. I would have assumed it was a bug.

I completely understand your point, and don't dispute that others will think as much from the start. However, even for us power users most of the status text and the like is quite useless. It looks techyish, but it's just going through the standard motions. The only time it's useful is when it's different from the standard path. The idea here is to only bother the user with info when it ~does~ differ from the standard path so instead of me having to read a pile of status text and find the bit that's meaningful, it does it automatically for me (at least to a starting degree). This is not just a dumbing down for the average user thing either; I personally would like it to be simpler for everyone, including myself.

Granted, the timing will have to be just right so it actually does show it when it's needed and not otherwise and not miss something either.

> And another though just occurred to me. I know there has been a fair amount of
> effort into improving Firefox's perceived performance. However, I think
> spottily displaying information in a delayed manor would be counterproductive
> to that endeavor. If anything, I think the main reason I keep around the full
> status text is that it gives Firefox a much more snappy and responsive feel.

That's an interesting argument, but I think throwing a bunch of extra text around doesn't really help (enough to care, at least). Something like bug 604027 might help with the GUI responsiveness to change part, but most people glaze over looking at the text. There's also the counter-argument to the perception part that frankly, I saw the text in the status bar as sort of an older boiler-plate part of the interface and once it was ditched things looked more quick because I no longer had any visual interruption with each unimportant step in the loading process. YMMV.

I guess my argument is that I want my browser to not try to dump all the info out there just because it has it but actually put out only info that may be vaguely useful.

(I think we've had a good discussion here, but we're beginning to clutter up the bug and get off topic a bit...)

Comment 15

[Alex Faaborg [:faaborg] (Firefox UX)]

>I guess my argument is that I want my browser to not try to dump all the info
>out there just because it has it but actually put out only info that may be
>vaguely useful.

I strongly agree with this argument, in fact we have a whole bugzilla keyword just for that concept: ux-implementation-level

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

I put a proposed design specification here, but I'm unsure if we get the events this way. If someone could point me to the code/docs where that happens, I'd be much obliged:

https://wiki.mozilla.org/Firefox/Projects/Connecting_Status#Design_Specification

Comment 17

[al_9x]

The user should be able to intuit the design, which they will not in this case, these delays and intermittent absence of data will appear as glitches/bugs and be annoying.  Just leave it the way it is, no one asked for it to be removed in the first place.

Comment 18

[Drew Willcoxon :adw]

Attachment: WIP patch

Here's a messy WIP patch.  For testing purposes the status text appears immediately rather than waiting for a second to elapse.

The design spec doesn't specify, but I assume the status text should be tab-modal, meaning it displays the loading status of the currently selected tab only.  If you select a different tab, the text should be updated to that tab's status (if any).  The old tab's loading status should be removed instantly, but whether we wait another second to show the newly selected tab's status I don't know, and I'll probably do what's easiest for me to implement.

The design spec mentions paint events triggering the throbber (and status text), but that's not how the throbber currently works.  It's based off of nsIWebProgressListener events.  I'm not planning on changing that.

A couple of unsolicited opinions.  1) This status text doesn't provide any information I can't glean from the dual-state throbber, which is nice and information-dense by itself.  As a user it's one more thing to distract my eye and one more thing to look at and understand.  As browser makers, it's one more thing for us to make sure gels with everything else the browser does visually when the user clicks a link.  2) Load up a big page like tabbrowser.xml in mxr.  Not only does the throbber get stuck every now and then, but now this new "Waiting..." status text gets stuck -- stuck as it's fading in, so it appears ghosted for a second or two; before it appears, until it briefly flashes in and out as the load finishes; or so that it does not appear at all.

Comment 19

[Dietrich Ayala (:dietrich)]

Great feedback, thanks Drew. Can you push this to try and link the builds here, so people can try it out?

Comment 20

[Drew Willcoxon :adw]

I'm working on a new patch that uses paint events for the throbber and text like the spec describes.  I'll post it later today along with tryserver builds.

Comment 21

[Drew Willcoxon :adw]

(In reply to comment #18)
> A couple of unsolicited opinions.  1) This status text doesn't provide any
> information I can't glean from the dual-state throbber

I'm wrong here.  The spec's pretty clear.  The counter-clockwise state of the throbber is divided in two: connection not established and connection established.  So that's two states.  After paint starts, the clockwise throbber starts, which is a third state.  I think I was writing from the perspective of not changing how the throbber currently works, and in that case there are only two states, and the text really doesn't provide any additional info.

Comment 22

[:Margaret Leibovic]

At some point there was also an idea to add a tooltip to the throbbers to explain what is going on in each state, but I'm having a hard time finding the bug on that.

I think the text in the location bar does provide additional information if it says which server resources the browser is waiting for/connecting to. I know my original WIP patch included that text, although I see that Beltzner's spec in the wiki does not include that, so feel free to ignore me if that is no longer part of the plan.

Comment 23

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #22)
> I think the text in the location bar does provide additional information if it
> says which server resources the browser is waiting for/connecting to.

Yes, this should still be the case. Apologies if that isn't clear. Just "Connecting" or "Waiting" doesn't help much, but "Waiting for ads.doubleclick.net" does.

Comment 24

[Drew Willcoxon :adw]

(In reply to comment #23)
> Yes, this should still be the case. Apologies if that isn't clear. Just
> "Connecting" or "Waiting" doesn't help much, but "Waiting for
> ads.doubleclick.net" does.

Really?  That's not what the spec says.  Beltzner, could you comment?

Comment 25

[Drew Willcoxon :adw]

Attachment: WIP patch 2

This patch is messy but feature complete with regard to the spec I think (barring any text changes alluded to in comment 24).  Tryserver builds will be here:

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-f749fedf625d

This patch and build have a couple of extras:

1) Loading progress is dumped to the terminal, so you can enable dumps and see when states change.  For each tab, the counter-clockwise throbber and "Connecting..." timeout start on "connection established"; the "Waiting..." timeout starts on the first "network progress"; the clockwise throbber starts on "MozAfterPaint received" (if it is received at all before the connection stops); and the throbber stops on "connection stopped".

2) You can change the timeouts by making a new integer preference named "loadingStatusTimeout" and setting it to a number in milliseconds.  If the pref doesn't exist, 1000ms is used.  By setting it to 0 it might be easier to get a sense of how things look.

Comment 26

[Drew Willcoxon :adw]

Well, bug 627225 is preventing the tryserver builds from... building.  I'll... try again when it's fixed.

Comment 27

[Drew Willcoxon :adw]

Oh, actually it looks like most of the builds finished OK.

Comment 28

[Mike Beltzner [:beltzner, not reading bugmail]]

Awesome, Drew - now I just need a slow server to test this on :)

re: comment 24, you're right, my design doesn't include the server that we're waiting for. Limi and Connor and I have discussed this a bunch offline, and we'll continue with this design for the time being. Playing with these tryserver builds will help a lot, as will being able to see the actual states.

More tomorrow morning ET.

Comment 29

[Alex Limi (:limi) — Firefox UX Team]

Yup, I've tested this too, and it's great to see the basic functionality working. I still think it's weird to just show "Waiting" when we don't say what we're waiting for, but we're going through that tomorrow to make sure we're on the same page as Beltzner on this.

There's a more in-depth treatment of this added to https://wiki.mozilla.org/Firefox/Projects/Connecting_Status#Design_Specification — where we talk about what should happen when slow resources on a different server are requested as part of a page.

Going over this with Beltzner tomorrow morning, as already mentioned.

Comment 30

[Mike Beltzner [:beltzner, not reading bugmail]]

Useful for testing: http://klausbach.com/?p=107 and http://www.devcurry.com/2010/07/simulate-slow-internet-connections.html

Comment 31

[Mike Beltzner [:beltzner, not reading bugmail]]

Based on feedback from the Mozilla module owner and others, we may be switching the spec to use a Chrome-like transient window that appears over content at the bottom left. I'll be working on that today, and may end up marking this bug a "Future". 

The WIP here is helpful, especially the console output. Some quick thoughts based on using it for a few days:

 - when I reduce my bandwidth (using the first link in comment 30) I don't see the indicators as much as I expect; perhaps that's because we're counting the first point of connection?

 - sometimes I saw "Waiting..." with the backwards throbber, which should indicate that a connection was being forged. We might need to do some fakery here, where we only start throbbing forwards once we hit that first paint event, as from the user's perspective everything else up to that point is considered and seen as "connecting"

 - Limi and the UX team feel strongly that "Connecting to ..." + eTLD will give the best sense of both activity (as it will change) and blamecasting. I disagree, but it's late to make changes that abstract detail, and so acquiesce to their will.

Comment 32

[dindog]

a really nice chrome like userchrome.js. I would help
https://gist.github.com/300255

Comment 33

[dindog]

a really nice chrome like userchrome.js. It would help
https://gist.github.com/300255

Comment 34

[Drew Willcoxon :adw]

(In reply to comment #31)
>  - when I reduce my bandwidth (using the first link in comment 30) I don't see
> the indicators as much as I expect; perhaps that's because we're counting the
> first point of connection?

The counter-clockwise throbber starts when the request is initiated.   (The patch dumps "connection established" at this point, which is really inaccurate.  I didn't understand how inaccurate until I looked at nsIWebProgressListener's doc just now.  I'm sorry about that!)  The patch starts the "Connecting..." timeout at this point also.

>  - sometimes I saw "Waiting..." with the backwards throbber, which should
> indicate that a connection was being forged. We might need to do some fakery
> here, where we only start throbbing forwards once we hit that first paint
> event, as from the user's perspective everything else up to that point is
> considered and seen as "connecting"

According to the spec, "Waiting..." should only appear with the counter-clockwise throbber, right?  When the paint event is fired, the clockwise throbber starts and the status text is cleared.  That's what the patch does.

Comment 35

[rob64rock]

(In reply to comment #31)
> Based on feedback from the Mozilla module owner and others, we may be switching
> the spec to use a Chrome-like transient window that appears over content at the
> bottom left. I'll be working on that today, and may end up marking this bug a
> "Future". 

Is bug 603777 now officially being moved to a future release or is it still
being consider for Firefox 4???

There's been no recent change of status of bug 603777 to indicate what the
official decision is since bug 628654 was filed.

Comment 36

[Mike Beltzner [:beltzner, not reading bugmail]]

Bug 628654 is now the hard blocker, this is not.

Comment 37

[amurderofcrows]

(In reply to comment #12)
> (In reply to comment #11)
> > IMHO there shouldn't be any delay. Users are used to what the status bar had,
> > and that's what they expect (at least that's what I've gathered from my
> > Status-4-Evar users). So if there is a delay to filter out information, I'd
> > expect some users to complain about 'data loss'.
> 
> These are not the average user and thus not an example of what we want for the
> default. Power users often want more, but the other few hundred million Firefox
> users need simplification. We're aiming for a compromise here, and those who
> want more will simply use an extension to get more. (which is a good thing)
> 

dear god, this last statement damn near lost me as a FF user forever.

NO NO NO NO NO NO NO!!!

it is NOT a good thing to use an extension to "get more" when the "more" is achieving the exact same functionality the browse USED to have.

this very idea is absolute fail.  continue "thinking" this way and you'll have a lot of people switch to something different.  Trust me on this one.  I worked for Yahoo Small Business for 3 years and it was often a fight to get people off the default browsers, either IE or Safari.  My customer was not the power user, but the average, barely skilled computer user.  people who hate change, and LOVE to complain about it. 

People who didn't want firefox simply because it was different, or because a past experience left them unhappy.

It was my personal goal to get people to switch to firefox from either IE or Safari, because it was BETTER. 

if you keep going down this path of removing or changing functionality and expecting people to use ADD-ONS to put that functionality back, i'll not only drop FF for chrome, but i'll suggest to our engineers that they elevate the use of webkit based browsers over FF.  chrome is fast becoming the "power user" choice anyway, and with all the Vista backlash causing people to run to Mac, safari has come up quite a bit as well.  Yahoo sites aren't all 100% friendly with webkit, but Yahoo should look into supporting these browsers more directly if Firefox decides it has become too good for its roots.

Comment 38

[Asa Dotzler [:asa]]

(In reply to comment #37)
[e-mail], your comments are out of line and inappropriate for Bugzilla. Bugzilla is not your message board. It is our workplace and I will not tolerate this kind of pollution.  I'm not sure what it is that you're doing in Bugzilla, but you're not helping here. If you'd like me to explain to you what Bugzilla is and where you might contribute productively, please reply to my email.

Comment 39

[Timofei Shatrov]

Bugzilla is, however, publically accessible, so if Firefox developers are going to degrade "average users" in order to justify removal of features, you can well expect "average users" to say something about it. Don't insult your users and you won't have angry users commenting on Bugzilla. Simple.

Comment 40

[Dave Garrett]

(In reply to comment #39 & comment #37)
The comment 37 panic attack quoted my comment 12 in response to comment 11. Just to clarify and attempt to avoid more panic (possibly in vain).

1) Anyone particularly phased by my statement needs to read everything more carefully, or not take general statements personally, or simply learn to work in groups better.

2) A very tiny portion of the hundreds of millions of Firefox users use addons. Firefox is written for the main group and those who use addons can customize at will beyond that if they need to (but are not expected to). This is not an insult; it's the reason Firefox and the addons system was created. For Firefox 4 some very old concepts are being replaced by new concepts (sometimes only slightly new but scary to some) that are intended to be better for as many people as possible. There are a lot of bleeding-edge-build users that panic at each change, but you're just going to have to wait a tiny bit to get used to it, or at least until everything is finished. Change happens, and it's usually for the better, but if you haven't noticed by now there have also already been multiple changes made for Firefox 4 betas that were changed again because it was decided they weren't the best possible change, so people need to remember that betas are not done and stop treating every change like it's the end of the world and calm down. Primary example: bug 628654 replacing this one.

3) Check my email address and listed name right now. Do you see "Mozilla" anywhere in there? No? That's probably because I'm just a volunteer and do not speak for Mozilla. (though I did file this bug on behalf of a Mozilla developer based on work in another bug)

4) Fundamentally, no "average users" post on Bugzilla using the meaning of "average" as "most common", and the vast majority of users doesn't know it exists. If you're reading anything here at all, you're at least "above average".

You don't need to reply to this post and I'm not going to get sucked into a pointless argument here so please avoid doing so. This isn't a forum, and I'm not going to post here on this off-topic again.