Closed Bug 544818 Opened 14 years ago Closed 14 years ago

Progress "Line" indicator for loading tabs

Categories

(Firefox :: Tabbed Browser, enhancement)

enhancement
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 4.0b7
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: shorlander, Assigned: Margaret)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(5 files, 22 obsolete files)

27.08 KB, image/png
Details
12.25 KB, image/png
Details
14.35 KB, image/png
Details
24.28 KB, patch
dao
: review+
Gavin
: review+
Details | Diff | Splinter Review
14.55 KB, image/jpeg
Details
A progress bar can make waiting seem slightly less painful and let you know if something might be hung-up or not. It won't actually make things faster but it might make them feel faster.

Instead of the indeterminate progress indicator in use now, we would like add a progress "line" at the top of each loading background tab. This will let people know about how much longer their background tabs have until they can be interacted with.

See attachment for mockup.
Blocks: 544820
Blocks: 544821
As a starting point, I wrote an add-on to implement this feature and only this feature:
https://addons.mozilla.org/en-US/firefox/addon/14644
It adds the "progress line" indicator to the active tab too, but that can be easily adjusted.

For the actual patch, it would probably be better to attach the progress line binding higher up in the DOM hierarchy than I did.
If these progress bars are going to have a glow-pulse around, while the page is being loaded, like the current ones on Mac OS X which fits in the favicon space, I suggest that after a minute, the pulsing stops. For reasons unknown to me, there are pages out there that never stop loading, but still remain fully functional. A forever-pulsing progress bar could be distracting.

Opinions?
We could just time out the load and consider that "loaded enough" removing the bar.  I think this is preferable to a zombie bar, even if we are on some level kind of deceiving the user.
On the other hand, information is information. Yesterday I had to wait minutes before the reply box on a forum was finally displayed. It is nice if you can see that on the tab, so that you don't focus it too early.
(In reply to comment #2)
> If these progress bars are going to have a glow-pulse around, while the page is
> being loaded, like the current ones on Mac OS X which fits in the favicon
> space, I suggest that after a minute, the pulsing stops. For reasons unknown to
> me, there are pages out there that never stop loading, but still remain fully
> functional. A forever-pulsing progress bar could be distracting.
> 
> Opinions?
For the user to actually know that the page is fully functional, the user would have to select said tab and therefore the tab would no longer be a background tab and the progress line would no longer appear.  But on the other hand, if the user is only waiting until the progress line to select the tab then they could be waiting forever so maybe a timer is needed.
(In reply to comment #2)
> For reasons unknown to
> me, there are pages out there that never stop loading, but still remain fully
> functional. A forever-pulsing progress bar could be distracting.
Do you have some examples ?
> For the user to actually know that the page is fully functional, the user would
> have to select said tab and therefore the tab would no longer be a background
> tab and the progress line would no longer appear.

Yes, but that still means that, if you put the page in a background tab while you are reading something else, it will keep glowing. I also got to ask, will there be an out-of-tabs progress bar for the current tab?

> But on the other hand, if
> the user is only waiting until the progress line to select the tab then they
> could be waiting forever so maybe a timer is needed.

Would this be a timer to remove the progress bar completely, or just stop the glowing?

> Do you have some examples ?

Yes, one, that I remember now at least: http://www.notalwaysright.com. I have not done much research into what the problem is, though.
(In reply to comment #7)
> I also got to ask, will
> there be an out-of-tabs progress bar for the current tab?
Yes, below the location bar.
You can see it on stephen's mockups
Can I make an argument that this should be on all tabs, regardless of if they're selected or not. Having UI that jumps around depending on the current context is... confusing. (i.e. Background tab is loading, you click on it, suddenly it looks like it isn't loading but really the progress bar has just moved somewhere else).
Isn't that what the pie chart throbber was for?
(In reply to comment #10)
> Isn't that what the pie chart throbber was for?

Yes, this is the "pie chart throbber" evolved :-)
The line for some reason makes the browser feel faster.  Traveling more distance in the same amount of time?  Hard to quantify.
(In reply to comment #11)
> (In reply to comment #10)
> > Isn't that what the pie chart throbber was for?
> 
> Yes, this is the "pie chart throbber" evolved :-)

Dao's blog post comments mentioned this, and also see bug 334697 comment 28.

(In reply to comment #5)
> therefore the tab would no longer be a background tab 

True.

> and the progress line would no longer appear. 

I thought that was why there is a foreground tab mockup showing progress bar on the bottom of the location bar.
(In reply to comment #13)
> (In reply to comment #5)
> > and the progress line would no longer appear. 
> 
> I thought that was why there is a foreground tab mockup showing progress bar on
> the bottom of the location bar.

So there is.  See the third mockup here https://wiki.mozilla.org/Firefox/4.0_Windows_Theme_Mockups
Assignee: nobody → sdwilsh
Status: NEW → ASSIGNED
Target Milestone: Future → Firefox 3.7a3
Attached patch v0.1 (obsolete) — Splinter Review
This is a work in progress.  More tomorrow!
Attached patch v1.0 Windows & global changes (obsolete) — Splinter Review
This is the changes needed for windows theme and the general code.  Ryan is going to upload the bits for OS X, and ddahl is going to do the same for Linux.
Attachment #430196 - Attachment is obsolete: true
Attachment #430382 - Flags: review?(gavin.sharp)
Comment on attachment 430382 [details] [diff] [review]
v1.0 Windows & global changes

Discussing some changes to this with Stephen right now...
Attachment #430382 - Flags: review?(gavin.sharp)
Comment on attachment 430382 [details] [diff] [review]
v1.0 Windows & global changes

>diff --git a/browser/base/content/tabbrowser.xml b/browser/base/content/tabbrowser.xml

>             onProgressChange : function (aWebProgress, aRequest,

>+              // Never, ever, go backwards.

If we do this, it should probably be in the nsBrowserStatusFilter. Need to think through the implications of this more, too.

>               if (this.mTotalProgress) {

>-                if (state != this.mTab.getAttribute("progress")) {
>-                  this.mTab.setAttribute("progress", state);
>-                  this.mTab.removeAttribute("stalled");
>-                  this._startStalledTimer();
>-                }

>+                this.mTab.setAttribute("progress", value);

Incompatible change (attribute has different values), but I guess we haven't shipped this yet, so I guess that's OK. Why remove the existing attribute check?

>   <binding id="tabbrowser-tab" display="xul:hbox"
>            extends="chrome://global/content/bindings/tabbox.xml#tab">

It would be really nice to be able to do this without changing the tab's anonymous content, and without an actual <xul:progressmeter> on each tab... That's probably wishful thinking, though.

>diff --git a/browser/themes/winstripe/browser/browser.css b/browser/themes/winstripe/browser/browser.css

> .tabbrowser-tab[busy] > .tab-icon-image {
>   list-style-image: url("chrome://browser/skin/tabbrowser/progress.png") !important;
>   -moz-image-region: rect(0, 16px, 16px, 0);
> }
> .tabbrowser-tab[busy][stalled] > .tab-icon-image {
>   list-style-image: url("chrome://browser/skin/tabbrowser/progress-pulsing.png") !important;
> }

These no longer match anything, and I imagine the images are unused now too.

> /* tabbrowser-tab focus ring */
> .tabbrowser-tab > .tab-text {
>   border: 1px dotted transparent;
> }
> 
> .tabbrowser-tab:focus > .tab-text {
>   border: 1px dotted -moz-DialogText;
> }

These selectors need updating too, right? Also some ".tabbrowser-tab[selected="true"] > .tab-close-button" selectors in browser.css.
Attached patch v1.1 Windows & global changes (obsolete) — Splinter Review
Updated colors and styling.
Attachment #430382 - Attachment is obsolete: true
Attachment #430420 - Flags: review?(gavin.sharp)
Attached patch v1.1 Windows & global changes (obsolete) — Splinter Review
Ugh; I forgot to upload the *right* patch so this was the same as 1.0
Attachment #430420 - Attachment is obsolete: true
Attachment #430428 - Flags: review?(vladimir)
Comment on attachment 430428 [details] [diff] [review]
v1.1 Windows & global changes

Looks fine, but I'm very interested to see what the Tp hit is!
Attachment #430428 - Flags: review?(vladimir) → review+
Comment on attachment 430428 [details] [diff] [review]
v1.1 Windows & global changes

Looks like none of my comments were addressed?
Attachment #430428 - Flags: review-
(In reply to comment #22)
> (From update of attachment 430428 [details] [diff] [review])
> Looks like none of my comments were addressed?
gwa I never saw that mail :(

(In reply to comment #18)
> If we do this, it should probably be in the nsBrowserStatusFilter. Need to
> think through the implications of this more, too.
Well, I know UX has wanted to do this before.  I thought we had made the statusbar do this before as well.  I'll look into the nsBrowserStatusFilter bits.

> Incompatible change (attribute has different values), but I guess we haven't
> shipped this yet, so I guess that's OK. Why remove the existing attribute
> check?
We'll never be notified for the same value, so it's not needed and results in an extra, unneeded call (getAttribute).

> It would be really nice to be able to do this without changing the tab's
> anonymous content, and without an actual <xul:progressmeter> on each tab...
> That's probably wishful thinking, though.
Suggestions welcome, but I can't think of any way to do this.

> These no longer match anything, and I imagine the images are unused now too.
Should we just remove all the busy/stalled stuff?

> These selectors need updating too, right? Also some
> ".tabbrowser-tab[selected="true"] > .tab-close-button" selectors in
> browser.css.
Missed those; yes they need updating as well.
Attachment #430428 - Attachment is obsolete: true
Attached patch v1.3 Windows & global changes (obsolete) — Splinter Review
This should address all your comments.
Attachment #430440 - Attachment is obsolete: true
Attachment #430457 - Flags: review?(gavin.sharp)
Attached patch v1.4 Windows and Linux (obsolete) — Splinter Review
Not sure about gnomestripe changes for these lines in winstripe:

.tab-close-button:hover,

1077 	

.tabbrowser-tab[selected="true"] > .tab-close-button:hover {

	1088 	

.tabbrowser-tab[selected="true"] > .tab-container-box > .tab-title-box > .tab-close-button:hover {

1078 	

  -moz-image-region: rect(0px, 28px, 14px, 14px);

	1089 	

  -moz-image-region: rect(0px, 28px, 14px, 14px);

1079 	

}

	1090 	

}

1080 	

	1091 	

1081 	

.tab-close-button:hover:active,

	1092 	

.tab-close-button:hover:active,

1082 	

.tabbrowser-tab[selected="true"] > .tab-close-button:hover:active {

	1093 	

.tabbrowser-tab[selected="true"] > .tab-container-box > .tab-title-box > .tab-close-button:hover:active {

1083 	

  -moz-image-region: rect(0px, 42px, 14px, 28px);

	1094 	

  -moz-image-region: rect(0px, 42px, 14px, 28px);

1084 	

}

	1095 	

}

1085 	

	1096 	

1086 	

.tabbrowser-tab[selected="true"] > .tab-close-button {

	1097 	

.tabbrowser-tab[selected="true"] > .tab-container-box > .tab-title-box > .tab-close-button {
Attachment #430457 - Attachment is obsolete: true
Attachment #430465 - Flags: review?
Attachment #430457 - Flags: review?(gavin.sharp)
Attachment #430465 - Flags: review? → review?(gavin.sharp)
Comment on attachment 430465 [details] [diff] [review]
v1.4 Windows and Linux

>diff --git a/browser/themes/gnomestripe/browser/browser.css b/browser/themes/gnomestripe/browser/browser.css

> .tabbrowser-tab[busy] > .tab-icon-image {
>   list-style-image: url("chrome://browser/skin/tabbrowser/progress.png") !important;
>   -moz-image-region: rect(0, 16px, 16px, 0);
> }
> .tabbrowser-tab[busy][stalled] > .tab-icon-image {
>   list-style-image: url("chrome://browser/skin/tabbrowser/progress-pulsing.png") !important;
> }

These lines need to go from gnomestripe as well.

The CSS changes required basically boil down to removing the old tab throbber style rules, and adjusting any selectors that depend on "tab-icon-image", "tab-text", and "tab-close-button" being direct children of the .tabbrowser-tab.

For gnomestripe, that means:

[gavin@gavin-mbp:~/mozilla/mozilla-central/browser]$ grepr -E "(tab-icon-image|tab-text|tab-close-button)" | grep gnomestripe
./themes/gnomestripe/browser/browser.css:.tab-icon-image {
./themes/gnomestripe/browser/browser.css:.tabbrowser-tab[busy] > .tab-icon-image {
./themes/gnomestripe/browser/browser.css:.tabbrowser-tab[busy][stalled] > .tab-icon-image {
./themes/gnomestripe/browser/browser.css:.tabbrowser-tab[busy][progress="1"] > .tab-icon-image {
./themes/gnomestripe/browser/browser.css:.tabbrowser-tab[busy][progress="2"] > .tab-icon-image {
./themes/gnomestripe/browser/browser.css:.tabbrowser-tab[busy][progress="3"] > .tab-icon-image {
./themes/gnomestripe/browser/browser.css:.tabbrowser-tab[busy][progress="4"] > .tab-icon-image {
./themes/gnomestripe/browser/browser.css:.tabbrowser-tab[busy][progress="5"] > .tab-icon-image {
./themes/gnomestripe/browser/browser.css:.tabbrowser-tab[busy][progress="6"] > .tab-icon-image {
./themes/gnomestripe/browser/browser.css:.tabbrowser-tab[busy][progress="7"] > .tab-icon-image {
./themes/gnomestripe/browser/browser.css:.tabbrowser-tab[busy][progress="8"] > .tab-icon-image {
./themes/gnomestripe/browser/browser.css:.tab-close-button > .toolbarbutton-icon {
./themes/gnomestripe/browser/browser.css:.tab-close-button {
./themes/gnomestripe/browser/browser.css:.tabbrowser-tab[selected="true"] > .tab-close-button {
./themes/gnomestripe/browser/browser.css:.tab-close-button:focus {
./themes/gnomestripe/browser/browser.css:#allTabs-tab-close-button {

Your patch got most of those, but you're missing the two mentioned above and this one:

./themes/gnomestripe/browser/browser.css:.tabbrowser-tab[selected="true"] > .tab-close-button {

(which needs to change the same way the its equivalent in winstripe is changing)
Attachment #430465 - Flags: review?(gavin.sharp) → review-
tab-container-box looks superfluous. You can make the tab itself orient its children vertically.
Comment on attachment 430465 [details] [diff] [review]
v1.4 Windows and Linux

>-.tabbrowser-tab:focus > .tab-text {
>+.tab-title-box:focus > .tab-text {
>   border: 1px dotted -moz-DialogText;
> }

tab-title-box isn't focusable.
(In reply to comment #28)
> tab-container-box looks superfluous. You can make the tab itself orient its
> children vertically.
We tried several approaches to avoid the vbox, and sadly they all failed.
How exactly did they fail?
(In reply to comment #31)
> How exactly did they fail?
content was centered on the tab and could only be fixed by setting flex="1" on the vbox.
align="stretch" fixes that. I'm not sure why tabs are -moz-box-align: center; in xul.css, though...
Attached patch updated patch (obsolete) — Splinter Review
This patch uses that to avoid the need for the vbox, addresses my comments about gnomestripe changes, and adds partial styling for Mac (just need to sort out the .tab-progress styling).
Attachment #430465 - Attachment is obsolete: true
Attached patch updated patch v2 (obsolete) — Splinter Review
The Mac styling needs work (just copied some of the winstripe styling for now). Otherwise I think this is complete.
Attachment #430651 - Attachment is obsolete: true
Attachment #430654 - Flags: feedback?(dao)
Comment on attachment 430654 [details] [diff] [review]
updated patch v2

>-.tabbrowser-tabs:not([closebuttons="noclose"]):not([closebuttons="closeatend"]) > .tabbrowser-tab[selected="true"]:not(:only-child) > .tab-close-button {
>+.tabbrowser-tabs:not([closebuttons="noclose"]):not([closebuttons="closeatend"]) > .tabbrowser-tab[selected="true"]:not(:only-child) > .tab-container-box > .tab-title-box > .tab-close-button {
>   display: -moz-box;
> }
> 
>-.tabbrowser-tabs[closebuttons="alltabs"] > .tabbrowser-tab:not(:only-child) > .tab-close-button {
>+.tabbrowser-tabs[closebuttons="alltabs"] > .tabbrowser-tab:not(:only-child) > .tab-container-box > .tab-title-box > .tab-close-button {
>   display: -moz-box;
> }

this is broken (still using .tab-container-box)

>+.tab-progress {
>+  -moz-appearance: none;
>+  min-height:0;

nit: space after :
Comment on attachment 430654 [details] [diff] [review]
updated patch v2

>-.tabbrowser-tab[selected="true"] > .tab-close-button {
>+.tabbrowser-tab[selected="true"] > .tab-title-box > .tab-close-button {
>   /* Make this button focusable so clicking on it will not focus the tab while
>      it's getting closed */
>   -moz-user-focus: normal;
> }
> 
> .tab-close-button:focus {
>   outline: none !important;
> }

Can all this be removed, since clicking a tab doesn't focus it?
I spun off some try server builds[1] of attachment 430465 [details] [diff] [review] + mac styling before hopping on a plane this morning and the mac and windows Tp4/CPU metrics seem to be ok (the linux builds failed for non-code related reasons). I'll merge the mac stuff with the latest patch when I'm more awake tomorrow :)

[1] https://build.mozilla.org/tryserver-builds/rflint@ryanflint.com-try-2220c6959ba0/
Comment on attachment 430654 [details] [diff] [review]
updated patch v2

>--- a/browser/themes/pinstripe/browser/browser.css
>+++ b/browser/themes/pinstripe/browser/browser.css

> .tab-close-button:hover,
>-.tabbrowser-tab[selected="true"] > .tab-close-button:hover {
>+.tabbrowser-tab[selected="true"] > .tab-title-box > .tab-close-button:hover {
>   list-style-image: url("chrome://global/skin/icons/closetab-hover.png");
> }
> 
> .tab-close-button:hover:active,
>-.tabbrowser-tab[selected="true"] > .tab-close-button:hover:active {
>+.tabbrowser-tab[selected="true"] > .tab-title-box > .tab-close-button:hover:active {
>   list-style-image: url("chrome://global/skin/icons/closetab-active.png");
> }

Aren't the second lines of the selectors redundant?

Gnomestripe's browser.css has the .tab-progress stuff appended to the end. It belongs in the /* Tabs */ section.

Apart from the code, I think this makes the UI unnecessarily complex. Session restore felt particularly jarring. One argument for doing this was that we could show both the favicon and the progress, but apparently we're not showing the favicon before the line disappears.
(In reply to comment #39)
> One argument for doing this was that we
> could show both the favicon and the progress, but apparently we're not showing
> the favicon before the line disappears.

Which leads us to ask: Is it technically possible to show the favicon before the line has reached 100%? Do we have access to it before then?
I tried this build here: https://build.mozilla.org/tryserver-builds/rflint@ryanflint.com-try-2220c6959ba0/try-2220c6959ba0-win32.zip
and it seems to have a bug.

- I copied a folder with 10 bookmarks to the personal toolbar
- middle clicked on this folder

and nothing happened.
I need to left click on this folder first to "activate" it. :)
I don't see this bug in the latest trunk nightly.
From the Mac styling in the tryserver build:

  -moz-appearance: none;
  /* XXX progressmeter-periodic-redraw provides no themeable pieces */
  -moz-binding: url("chrome://global/content/bindings/progressmeter.xml#progressmeter");

Why is this an XXX comment? On Mac the binding goes hand in hand with the -moz-appearance, so I think this is just the way it should be.
Attachment #430654 - Flags: feedback?(dao)
(In reply to comment #40)
> Which leads us to ask: Is it technically possible to show the favicon before
> the line has reached 100%? Do we have access to it before then?
Yes, but we'd have to add some magic to moz-anno protocol, but we could easily try to get it from places first (I'm actually surprised we don't now).
Why are you hardcoding colours in gnomestripe? Can't you use Highlight somewhere, maybe even use multiple backgrounds with RGBA gradients to achieve the desired effect?
Depends on: 550825
Regardless, please don't use hardcoded colours in gnomestripe. I've been smacked down for using slight variants of theme colours, so this would obviously be unacceptable :-)
>Regardless, please don't use hardcoded colours in gnomestripe

I totally get why hard coded colors causes all sorts of problems for accessibility and just general usability as OS themes change, and I agree that we really can't use hard code colors.  But the additional problem is that the colors available to us are for really basic aspects of the UI, and it makes it pretty much impossible for us to implement anything at the fidelity of one of Stephen's mockups.  So I think the best path is to solve both problems over in bug 546816, which is blocking development of the new Firefox theme.  This way we can select on the known popular OS themes and look great, and fall back to safe colors if we run into an OS theme that we didn't anticipate.
As Michael said, we can probably use the Highlight color combined with an RGBA gradient. You shouldn't need to target specific OS themes for that, and we also don't really want it in this case.
(In reply to comment #9)
> Can I make an argument that this should be on all tabs, regardless of if
> they're selected or not. Having UI that jumps around depending on the current
> context is... confusing. (i.e. Background tab is loading, you click on it,
> suddenly it looks like it isn't loading but really the progress bar has just
> moved somewhere else).

I agree whit this.
Is there even ONE argument to place the same thing on different places?
Only if a user hides the tab bar (if still possible in Firefox 4.0)
We could have the progress line on both the tab and the address bar.
(In reply to comment #49)
> We could have the progress line on both the tab and the address bar.

We could do that, but we probably wouldn't want to...
This bug is only about adding the progress line to *all* the tabs.  Additional changes should go into a follow-up unless the goal is to stall this into oblivion.
Thnks for clearing things up

I had read the whole bug, but before comment 9 they spoke about something like a different loading bar on an other place...

So no follow-up needed for now
Summary: Progress "Line" indicator for background loading tabs → Progress "Line" indicator for loading tabs
The active tab is going to get a progress bar placed at the bottom of the location bar, so that it has a natural mapping with the placement of the stop button.  For inactive tabs the location bar obviously isn't visible, so the progress indicator moves to the tab itself.
Assignee: sdwilsh → rflint
When it will be in trunk?
(In reply to comment #54)
> When it will be in trunk?

It will be in the trunk when there is time to make and develop it
I'm wondering. Earlier mockups have PL with glow effect when tabs on top. Why it was abandoned? It looks nice and it makes PL easier to notice, especially when using greener desktop and/or high resolution.
I believe it may have been impossible to implement in a way that was didn't hinder performance, but sdwilsh or rflint would know more.
(In reply to comment #57)
> I believe it may have been impossible to implement in a way that was didn't
> hinder performance, but sdwilsh or rflint would know more.
We couldn't get the svg blur filter to work at all.
Where did you put the <svg:filter> element? Into browser.xml? You might have to put it into progress.xml. (Not sure if that restriction intentional... I should file a bug.)
(In reply to comment #59)
> Where did you put the <svg:filter> element? Into browser.xml? You might have to
> put it into progress.xml. (Not sure if that restriction intentional... I should
> file a bug.)
We had placed it in browser.xul with some other svg filters and tried adding it via css.
Yeah, then moving it to progressmeter.xml could do the trick.
Attached patch Patch (obsolete) — Splinter Review
* Doesn't remove the statusbar progressmeter yet.
* No glow in this iteration. SVG performance is such that I would prefer not using it unless we absolutely must. If we want to add some form of glow, I think a small, fixed-width, box-shadowed spacer at the leading end of the bar would probably be a decent compromise.
* We definitely need some form of visual feedback when progress is stalled.

(In reply to comment #37)
> (From update of attachment 430654 [details] [diff] [review])
> >-.tabbrowser-tab[selected="true"] > .tab-close-button {
> >+.tabbrowser-tab[selected="true"] > .tab-title-box > .tab-close-button {
> >   /* Make this button focusable so clicking on it will not focus the tab while
> >      it's getting closed */
> >   -moz-user-focus: normal;
> > }
> > 
> > .tab-close-button:focus {
> >   outline: none !important;
> > }
> 
> Can all this be removed, since clicking a tab doesn't focus it?

From a quick test, the first still appears to be applicable. The second could probably be removed since I don't see anything setting an outline anymore, but I don't have any way to test on Linux at the moment.
Attachment #430654 - Attachment is obsolete: true
Attachment #435137 - Flags: review?(dao)
I'm not exper on this, but couldn't bu used GPU acceleration of some kind for PL? I know Aero in Win7 is using D2D (if it is somehow helpful).
(In reply to comment #63)
> I'm not exper on this, but couldn't bu used GPU acceleration of some kind for
> PL? I know Aero in Win7 is using D2D (if it is somehow helpful).

Good point. The acceleration provided would surely be more than enough. But that's still just two OS's/platforms. Still, better than none, I guess.
Linix has OpenCL and I think Mac as well.
(In reply to comment #65)
> Linix has OpenCL and I think Mac as well.

Indeed, and bugs have been filed to start working on those, but so far, Windows is the priority and the only OS to have a "working" implementation.
Attachment #435137 - Flags: review?(dao) → review?(gavin.sharp)
Comment on attachment 435137 [details] [diff] [review]
Patch

>diff --git a/browser/base/content/tabbrowser.css b/browser/base/content/tabbrowser.css

>+.tabbrowser-tab[selected="true"] > .tab-progress,
>+.tabbrowser-tab:not([stalled]):not([progress]) > .tab-progress {
>+  display: none;
>+}

Why :not([stalled])? Doesn't :not([progress]) cover all the cases we want it hidden?

I think we should probably hold off on hiding the selected tab's progress line until we have the global one hooked up - as it is this patch removes all status indicators for active tabs, which isn't very good.

>diff --git a/browser/base/content/tabbrowser.xml b/browser/base/content/tabbrowser.xml

>               if (this.mTotalProgress) {
>-                const STATES = 8;
>-                let state = Math.ceil(STATES * this.mTotalProgress);
>-                if (state != this.mTab.getAttribute("progress")) {
>-                  this.mTab.setAttribute("progress", state);
>-                  this.mTab.removeAttribute("stalled");
>-                  this._startStalledTimer();
>-                }
>+                let value = Math.ceil(this.mTotalProgress * 100);
>+                this.mTab.setAttribute("progress", value);
>+                this.mTab.removeAttribute("stalled");
>+                this._startStalledTimer();
>               }

I think it's worth adding a comment here that we don't need to worry about updating too much or going backwards thanks to the browser status filter (batches changes, avoids notifying us of changes <3%, doesn't go backwards).

>diff --git a/browser/themes/pinstripe/browser/browser.css b/browser/themes/pinstripe/browser/browser.css

>+.tabbrowser-tab {
>+  -moz-box-direction: reverse;
>+}

What's this for? Add a comment?

>+.tab-progress {
>+  -moz-binding: url("chrome://global/content/bindings/progressmeter.xml#progressmeter");

Why is this needed?

I didn't test this on Windows/Linux, I'm assuming you've done that. It would be good to have Dao look over the CSS changes as well since I didn't look closely at the styling.
Attached image Linux screenshot (obsolete) —
Looks quite messed up on Linux
Is this still gonna happen or will minefield be sticking with the pie charts?
still going to happen
Before Christmas?
(In reply to comment #71)
> Before Christmas?

Please, hold your mesh yourself.
This is no place for it, and you have spammed 50 users with it.
I think adding a progress bar to the tabs is a bad idea. The introduction of too many little graphics animating everywhere in the browser is pretty annoying. Opera browser does is quite often. Their progress bar indicates how many images has been loaded out of the many that exist. That is use this information for me and serves no purpose. I can see that it has not know it by just looking at the screen.

Most of the time, the progress bar is pretty useless when most of the time webpages load up pretty quickly. I think a progress bar should only be shown when a webpage takes more than 2 seconds to load. Then it is advisable indicate that the webpage is not yet loaded.
(In reply to comment #73)
> I think adding a progress bar to the tabs is a bad idea. The introduction of
> too many little graphics animating everywhere in the browser is pretty
> annoying. Opera browser does is quite often. Their progress bar indicates how
> many images has been loaded out of the many that exist. That is use this
> information for me and serves no purpose. I can see that it has not know it by
> just looking at the screen.
> 
> Most of the time, the progress bar is pretty useless when most of the time
> webpages load up pretty quickly. I think a progress bar should only be shown
> when a webpage takes more than 2 seconds to load. Then it is advisable indicate
> that the webpage is not yet loaded.

We currently have throbbers. Switching those for progress lines is merely swapping out something that doesn't tell you very much for something that's more informative.

I don't find your argument against them very compelling at all. I'm sure you can install a skin to remove them for yourself.
(In reply to comment #74)
> We currently have throbbers. Switching those for progress lines is merely
> swapping out something that doesn't tell you very much for something that's
> more informative.

The throbber replaces the favicon, so adding a distinct progress element increases visual complexity. The progress line isn't more informative than a determined throbber, like the one still on trunk, but it conveys the information more traditionally and arguably more obviously (the positive way of putting the visual complexity).
Comment on attachment 435137 [details] [diff] [review]
Patch

see attachment 435920 [details]
Attachment #435137 - Flags: review?(gavin.sharp) → review-
(In reply to comment #74)
> (In reply to comment #73)

> We currently have throbbers. Switching those for progress lines is merely
> swapping out something that doesn't tell you very much for something that's
> more informative.
> 
> I don't find your argument against them very compelling at all. I'm sure you
> can install a skin to remove them for yourself.

wow, I never noticed that the throbbers were there. I think the robbers does a really good job of indicating what I want to know which is if the page is loaded. Once I see the favicon, I know that the page is loaded.

If Firefox decides to go with a progress bar, I hope they include an option to leave the current option as is. I don't like the idea of having to make a skin because I don't know how and I don't have the time.

The progress bar might be better suited for a tab for the downloads window.
As Alex tweeted long before , Progress bars give an impression of quickness and we "feel" that its loading faster.
I think somebody needs to do a quick research and asked users which one they feel is faster. I don't know where Alex got that idea. Hopefully he got the idea from some research paper and not his personal  opinion.
He probably got it from the Microsoft UX Guidelines. It says that there as well.

http://msdn.microsoft.com/en-us/library/aa511486%28v=MSDN.10%29.aspx
(In reply to comment #79)
> I think somebody needs to do a quick research and asked users which one they
> feel is faster. I don't know where Alex got that idea. Hopefully he got the
> idea from some research paper and not his personal  opinion.

There's already an option there. I'm sure a TestPilot case would prove the vast majority of users have text disabled. If you'd like the text moved to beside the icon, maybe it'd be a lot less hassle to create an extension? Which may in turn promote option you want and see it folded into the main release at a later date.
And its not at all his personal opinion , he did not even comment on it, he just reported us
Actually, its by CMU Researchers  (check above link)
According to the Microsoft UX Guidelines:

Will the operation complete in about five seconds or less?
If so, use an activity indicator instead, because displaying a progress bar for such a short duration would be distracting. If the operation usually takes five seconds or less but sometimes takes more, start with a busy pointer and convert to a progress bar after five seconds.
Our objectives are:

1) show visual feedback in a way that is clearly noticeable (if the user doesn't notice any form of feedback, then it is failing at it's purpose of indicating the status of the system)

2) show feedback in a way that feels fast.  This is complex, because humans don't really have an internal chronometer that can be used to accurately represent time.  For instance animations that accelerate over time appear faster (which can be applied to either a bar or circle like the mouse cursor in windows)


Also fun reading about progress bars, file copy operations in Vista were literally faster than XP but perceptual slower: http://www.codinghorror.com/blog/2008/03/actual-performance-perceived-performance.html
(In reply to comment #85)

> Also fun reading about progress bars, file copy operations in Vista were
> literally faster than XP but perceptual slower:
> http://www.codinghorror.com/blog/2008/03/actual-performance-perceived-performance.html

I read this report before. I am aware of perceive performance versus actual performance and personally I prefer a faster perceived performance.

> Our objectives are:
> 1) show visual feedback in a way that is clearly noticeable (if the user
> doesn't notice any form of feedback, then it is failing at it's purpose of
> indicating the status of the system)

I think a progress bar for webpages that take more than 5 seconds to load would be a good idea. However if a webpage takes less than 3 seconds to load, I wouldn't be too concerned and ask for it anupdate on it's progress.

When I go to McDonald's, I never really worry about the progress of my food because it is quite quickly how they make it. However when I'm at a restaurant, I always seem to want to an update as to when will they finish cooking my food because it always seems to quite a while.
(In reply to comment #86)
> (In reply to comment #85)
 
> When I go to McDonald's, I never really worry about the progress of my food
> because it is quite quickly how they make it. However when I'm at a restaurant,
> I always seem to want to an update as to when will they finish cooking my food
> because it always seems to quite a while.
OT on
That's because you will get REALL food in restaurant...
OT off

Practice has showed that users like and want PL. Furthermore, we PL will be only on background tabs. How can you tell the page is loaded when you can't see it until you click on tab? How many times happaned that page doesn't load at all due the server error?
Attached patch WIP (obsolete) — Splinter Review
haven't tested pinstripe yet
Assignee: rflint → dao
Attachment #435137 - Attachment is obsolete: true
Attached patch patch (obsolete) — Splinter Review
Attachment #435920 - Attachment is obsolete: true
Attachment #447337 - Attachment is obsolete: true
Attachment #447581 - Flags: review?(gavin.sharp)
(In reply to comment #67)
> >+.tab-progress {
> >+  -moz-binding: url("chrome://global/content/bindings/progressmeter.xml#progressmeter");
> 
> Why is this needed?

It overrides <http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/pinstripe/global/global.css#56>. We don't want/need the periodic-redraw binding here.
Keywords: icon
Target Milestone: Firefox 3.7a3 → ---
Version: unspecified → Trunk
Will PL have blur effect, or it is 100% impossible?
(In reply to comment #91)
> Will PL have blur effect, or it is 100% impossible?

I suppose you mean the glowing around the line itself. If so, the reason for not having it is that it might, or will, have an impact on performance. My personal opinion is that the line doesn't look good at all without it, and I'd prefer shipping the current tab-throbber version instead of a line without glow.
(In reply to comment #92)
> My
> personal opinion is that the line doesn't look good at all without it, and I'd
> prefer shipping the current tab-throbber version instead of a line without
> glow.

Actually, seeing as the latest mock-ups have compensated for this, it doesn't look too bad. I withdraw my statement.
(In reply to comment #92)
> (In reply to comment #91)
> > Will PL have blur effect, or it is 100% impossible?
> 
> I suppose you mean the glowing around the line itself. If so, the reason for
> not having it is that it might, or will, have an impact on performance.
As I said earlier, we have D3D9, D2D, DW, WebGL and God knows what else for GPU acceleration. Why not use it for glow as well?
Sorry for being so impatient. But it seems that this bug has been up for review for quite some time.
Blocks: 572482
Two weeks later...no review lol
Two weeks? A month!
Please don't spam. This is not a forum. Your comments should only be about fixing the bug.
i think the progress line would look better at the bottom of the tab as this is the darkest part of the tab and it does not look out of place. I added a black line behind the progress line to make it stand out more than it does in the other mockup.
(In reply to comment #99)
> to make it stand out more than it does in the other mockup.

You must be joking...
(In reply to comment #100)
> (In reply to comment #99)
> > to make it stand out more than it does in the other mockup.
> 
> You must be joking...

Don't start flaming people, this isn't deviantart.
If you don't agree with s/he, create your own mockup or state the reasons why.

Sorry for the spam mail people.
(In reply to comment #99)
> Created an attachment (id=455493) [details]
> [Mockup] Progress line at bottom of tab
> 
> i think the progress line would look better at the bottom of the tab as this is
> the darkest part of the tab and it does not look out of place. I added a black
> line behind the progress line to make it stand out more than it does in the
> other mockup.

It actually looks worse than original mockup because progress line blends with bright bar right beneath it. On original mockup progress like is contrast to everything around it and clearly noticeable.
(In reply to comment #101)
> Don't start flaming people, this isn't deviantart.
Don't know what are you talking about.
> If you don't agree with s/he, create your own mockup
Don't need to, there already is one, which is perfect as it is.
> or state the reasons why.
Subjectively:
1. Looks ugly.
Objectively:
1. Inconsistent
2. Inlogical
3. Hard to notice
4. Misplaced
5. If there will be two pages next to each other, PL will appear as a one line, thus making it useless thing
Do I REALLY need to state the obvious? Not to mention there was enough time to adress ideas to UX team, now it's WAY too late. Bugzilla isn't place for it anyway.
(In reply to comment #103)
> (In reply to comment #101)
> > Don't start flaming people, this isn't deviantart.
> Don't know what are you talking about.
You were, at a minimum, being uncivil.  Please see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html for how to properly behave on bugzilla (specifically 1.1 and 1.3).
I'm used to be unconventional. I'll try to reduce that aspect of my personality here on Bugzilla. It's just when I saw this "great" ideas, I sometimes explode. Sorry for that.
On topic, are we 100% not going to include a glowing effect?
Discussion should be made in the NewsGroups.
http://groups.google.com/group/mozilla.dev.usability/topics
(In reply to comment #106)
> On topic, are we 100% not going to include a glowing effect?
I think there are technical issues with implementing it currently.  If those can be overcome, maybe we can have it, but it should be done in a follow-up bug.
Can we use GPU acceleration for it?
(In reply to comment #109)
> Can we use GPU acceleration for it?
To be clear, the technical limitation was that we could not get the blur effect to even work, not that it was slow (although we'd likely have that issue as well).
The limitation comes from Firefox itself? If yes, can it be removed? (If yes, in Firefox 4? :) )
(In reply to comment #111)
> The limitation comes from Firefox itself? If yes, can it be removed? (If yes,
> in Firefox 4? :) )
It's not clear what the limitation is.  More work would have to be done investing it, and I suspect we have higher priority things to get fixed for Firefox 4.
I see... Well as I said, a simple green line is not easy to notice on green backgrounds. Glow effect would be very helpful.
Have you tried to accomplish it by applying a box-shadow to the line itself?
(In reply to comment #114)
> Have you tried to accomplish it by applying a box-shadow to the line itself?
That was one approach we tried, yes.  That may even be in the current iteration.
Shouldn't the progress line for the urlbar be higher priority than this?
No, as the PL, regardless it's position, is the same. PL in adress bar will be in follow up bug.
Perhaps my opinion doesn't matter here, but the progress circle we have now might be a better choice after all. People in the feedback section seems to like it a lot, and it covers the favicon so that we don't have to display an unloaded one. I suggest that we WONTFIX this bug (as we also have the performance issues), and set our aim towards making a nicer looking progress circle for the final release, instead. Basically, it just requires some coloring.
Magne, have you read comment #75, 78 and others?
(In reply to comment #118)
i guess i'm not the only one. :)
Well with this work already done, we can land it on the nightlies and see how it's received, if it's poorly we can always revert to the current approach. It never hurts to try new things.
Blocks: 578028
What is the post-summit plan here? If you plan to use progress bars, fixing bug #572488 before that would make a lot of sense (new tab style for linux)
Even Windows don't have them, only Mac. And they are not required to get it work.
Blocks: 577132
(In reply to comment #122)
> What is the post-summit plan here? If you plan to use progress bars, fixing bug
> #572488 before that would make a lot of sense (new tab style for linux)

I agree it would be nice to have that fixed for this. We also need a way to get the progress bar color in Linux.
Can we have glow for purposes of bug 577132, please?
(In reply to comment #124)
> We also need a way to get the progress bar color in Linux.

IIRC I also discussed this with Michael Ventnor at the summit. We won't be able to match normal progress bar colors, as engines are free to style them as they please. But we can probably just use a variation of the selected item color.
(In reply to comment #124)
> (In reply to comment #122)
> > What is the post-summit plan here? If you plan to use progress bars, fixing bug
> > #572488 before that would make a lot of sense (new tab style for linux)
> 
> I agree it would be nice to have that fixed for this. We also need a way to get
> the progress bar color in Linux.

(In reply to comment #126)
> (In reply to comment #124)
> > We also need a way to get the progress bar color in Linux.
> 
> IIRC I also discussed this with Michael Ventnor at the summit. We won't be able
> to match normal progress bar colors, as engines are free to style them as they
> please. But we can probably just use a variation of the selected item color.

After looking at gtkrc files for some common themes, we can't get a colour value for the progress bar. This shouldn't matter anyway since 9 times out of 10 its the same as the Highlight CSS colour anyway.
Does the patch also include displaying the progress line for the current tab?
"Progress "Line" indicator for loading tabs"
Which means for all tabs.
requesting to block beta2+
I don't think this will make into beta 2, as the code freeze is very near. But I hope I'm wrong.
Not Possible to block Beta 2+ since Beta 2 code freezes at 19th July 2300 PDT.
(In reply to comment #132)
> Not Possible to block Beta 2+ since Beta 2 code freezes at 19th July 2300 PDT.

I thought that was a tentative date? And I'm presuming that all we need is review+ from Gavin to land this, unless there are other issues to work out.
Judging from Dao's comments, there aren't any. But may rise some when Gavin review the patch. If, and I mean IF, this gets r+ today and lands today, we will have PL for beta2, but that seems very unlikely, because they are focusing on something else.
There may be issues with app tabs. (Like, it's not designed for that case at all.)
As far as I know, AppTabs won't have PL.
Given the size of AppTabs, it may be better to retain the current throbber for those cases.
For App Tabs, different approach can be used.(I am talking about Background App Tab Visual Feedback, Active App Tab should use PL in the location bar)

Idea ONE.
We can be creative and use the website logo for visual feedback for loading. 

In the beginning, there is no logo in the App Tab. When loading is half complete, half of the logo is visible. When loading finishes, the entire logo is visible.

If the website has no logo, use the Firefox logo instead.

Idea TWO.
We can still use PL. But make PL height almost the same as the tab. 

In the beginning, there is no PL in the App Tab. When loading is half complete, half of the PL is visible. When loading finishes, the entire PL is visible.

Making the PL taller allow users to see the Progress Line more clearly. 

Idea THREE.
Use the Coloured version of the Current Throbber or redesigned Throbber. 

Redesigned Throbber just meant that the throbber is redesigned to look better (example add glowing effect).
(In reply to comment #138)

I think Idea One is the best one. Overlay a throbber over the favicon. However I'm not a fan of the fallback of the Firefox icon. In the extremely rare cases that a web application has no favicon, it'd be best to use a specific appicon Icon.

Currently though, AppTabs require a lot of work, at the moment they're still just mini tabs. I'd actually suggest shipping beta2 with them disabled, there's little if any feedback to be gathered.
(In reply to comment #138)
> For App Tabs, different approach can be used.(I am talking about Background App
> Tab Visual Feedback, Active App Tab should use PL in the location bar)


It won't, AppTabs will be chromeless.
Blocks: 579521
Is this wanted for 4.0 ?  Requesting blocking - review been pending since May. Or, perhaps the idea has been re-thought and should be marked WONTFIX.
blocking2.0: --- → ?
This is definitely wanted for Firefox 4.0 . There are no suggestion by any dev that this has been cancelled. Currently, devs are busy with other bugs, so do wait for a little while longer.
If this is still the desired design. Shorlander: if this is still the design, please renominate.
blocking2.0: ? → ---
Blocks: 574688
Assignee: dao → nobody
Status: ASSIGNED → NEW
(In reply to comment #138)
Idea FOUR.
We can bend the progress line around the favicon (just like a border for it: square or rounded).
That will: 1. visually differentiate AppTabs loading progress from regular tabs' loading progress.
2. match the other Fx part styling.
Idea FIVE.
We can make the progress bar as sparkles with fancy sound effect.

Sheesh...
(In reply to comment #145)
> Idea FIVE.
> We can make the progress bar as sparkles with fancy sound effect.
> 
> Sheesh...

Henky, I have seen you being pretty mean in a couple of bugs now, and you have already been warned. Those kind of posts do not belong here.
(In reply to comment #144)
> (In reply to comment #138)
> Idea FOUR.
> We can bend the progress line around the favicon (just like a border for it:
> square or rounded).
> That will: 1. visually differentiate AppTabs loading progress from regular
> tabs' loading progress.
> 2. match the other Fx part styling.

I think I can imagine how it would look, but I see no room for it. Would you be able to create a mock-up roughly showing how you think?
(In reply to comment #146)
> (In reply to comment #145)
> > Idea FIVE.
> > We can make the progress bar as sparkles with fancy sound effect.
> > 
> > Sheesh...
> 
> Henky, I have seen you being pretty mean in a couple of bugs now, and you have
> already been warned. Those kind of posts do not belong here.

Square progress bar is less absurd than sparkles? That may be, but they are both stupid. Trying to help is one thing, but trying to help at any price isn't helping anyone (I learned that myself). How is that if I did the same thing I get warning, but if someone else did it, he gets support?
I don't understand why ideas are being put forward for alternatives to the progress line, has this been nixed or is it still going ahead?
My point exactly. The decission has been made, the patch is pretty much done, feature-freeze is very close. If there was space and time for suggestions, it isn't now.
This bug is essentially dead - the patch author has unassigned himself thus basically withdrawing his patch.  Its not marked as blocking or wanted for 4.0, so this one is over...

As to why it was not just marked WONTFIX I don't know...
Because this bug is still wanted for Firefox release. WONTFIX meant this bug is never going to be released ever in the future.
+ new idea: change the color for active tab from green to orange, for example.
Than a user will distinguish an active tab easier.
(In reply to comment #153)
> + new idea: change the color for active tab from green to orange, for example.
> Than a user will distinguish an active tab easier.

Bug 577132.
This bug is a bit loud now... Here is the simplest way forward I see:

1) Finish implementing the basic progress line bar on top of all tabs. Stop worrying about every side problem in the same bug. This needs to get in because:
  a) comment 85
  b) It's one of the more popular part of the mockups.
  c) It's good information that looks good.
  d) The old progress bar should be going away with status bar removal.

2) Stick a spinning throbber on loading app tabs and call it a day. File a new bug to come up with something better if it's really needed, but it's not that big of an issue really.
blocking2.0: --- → ?
Just noticed this today on planet mozilla: 
http://hacks.mozilla.org/2010/08/mozelement/ 

particularly this: would this help here or just what's been tried already?
http://hacks.mozilla.org/wp-content/uploads/2010/08/flowinggradient.html
somebody just review it and land it for feedback first please.
I second that.
Attachment #447581 - Attachment is obsolete: true
Attachment #447581 - Flags: review?(gavin.sharp)
This blocks the status bar replacement in bug 574688, so is also blocking+.
blocking2.0: ? → beta6+
I think that the new activity indicator (the throbber over the favicon in the tabs) gives more information than this progress line. I mean, even if the completion of the circle is stopped, the entire icon is beating (from tranlucent to normal). In that way it helps the user understanding that something is happening (like negociating with a server but waiting for an answer).
(In reply to comment #160)
> I think that the new activity indicator (the throbber over the favicon in the
> tabs) gives more information than this progress line. I mean, even if the
> completion of the circle is stopped, the entire icon is beating (from
> tranlucent to normal). In that way it helps the user understanding that
> something is happening (like negociating with a server but waiting for an
> answer).

The regular throbber did the exact same thing. Showed activity.
Attached image throbber with progress (obsolete) —
(In reply to comment #161)
> (In reply to comment #160)
> > I think that the new activity indicator (the throbber over the favicon in the
> > tabs)
> 
> The regular throbber did the exact same thing. Showed activity.

Yes, but the new one show progress too ;-)(so activity and progress)

(Sorry to post a new attachement here, I haven't found the bug related to this throbber)
Also, the progress line ideas are prettier than the pie throbber.
(In reply to comment #163)
> Also, the progress line ideas are prettier than the pie throbber.

There was a prettier pie chart throbber in an early theme mockup, but that disappeared shortly after. Other than that, we haven't spent a minute on polishing it.
Can we PLEASE stick to the original plan? This entire discussion of chaging it is freakin' me out!
Peter: Calming thoughts.....

Though, yes, I agree, I would prefer sticking close to the mockups with the line.

Why are all patches marked obsolete, by the way? Shouldn't the latest not be?
(In reply to comment #166)
> Why are all patches marked obsolete, by the way?

Try applying them, they won't work.
(In reply to comment #167)
> (In reply to comment #166)
> > Why are all patches marked obsolete, by the way?
> 
> Try applying them, they won't work.

I was under the impression that obsolete implied no longer needed, not necessarily no longer functional, in that the latest WIP is not obsolete. I only bring it up because of Bugzila's new-ish feature to autohide them and thus hide these older works in progress.
Obsolete doesn't necessarily mean replaced, just literally obsolete. (I'm not a native speaker, but I'm pretty sure it has a clear literal meaning.)
Literal meanings don't always translate to technical usage. Sorry, this is off topic anyway. It was just a procedural question that may not have a hard defined answer. If Bugzilla didn't hide them all by default it wouldn't matter.

Regardless, this is still blocking beta6+, so one of the 5 people who have contributed to patches here could hopefully continue the work? If not, is someone else available? This is a very nice feature idea that looked to be a cornerstone of part of the new GUI.

Also, more progress here would apparently lower Peter's blood pressure. :p
Honestly, at this stage, the UI of firefox 4b6 is remarkable similar to those of Opera and Chrome.

This would definitely be a shining difference. I think it greatly improve the unique-ness of firefox.

I don't understand why UI team is not hard working on this, I don't think 90% carbon copy of chrome/Opera UI with no differences should be the final goal of fx UI team.
(In reply to comment #171)
> 
> This would definitely be a shining difference. I think it greatly improve the
> unique-ness of firefox.

I don't think being different is the goal.
does anyone notice the flashing icon annoying besides me.
(In reply to comment #172)
> (In reply to comment #171)
> > 
> > This would definitely be a shining difference. I think it greatly improve the
> > unique-ness of firefox.
> 
> I don't think being different is the goal.

not for the sake of being different. 

but current goal seems to be "same as opera and chrome". thats not a good idea, imho.
(In reply to comment #171)
> I don't think 90% carbon copy of chrome/Opera UI with no differences
> should be the final goal of fx UI team.

(In reply to comment #174)
> but current goal seems to be "same as opera and chrome".

It isn't. Firefox 4 is not what you describe and is not done.

This is the land of open source and open ideas. If *anyone* has a good idea it should get used by others. Google uses Mozilla code; Mozilla uses Google code. Ideas are shared and rehashed and competitors taking good ideas just makes the entire software ecosystem better, with better software overall. (and everyone "borrowed" windowing ideas form Xerox in the first place) We don't need a debate on copying good ideas here, though.

This bug is a new good and unique idea for us, and yes we want it, but extraneous comments aren't constructive. This isn't really a forum.

Please don't argue any more in relation to "the other guys" in this bug. Let's please try to reign in this bug to its actual topic of the progress lines.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Only 5 days remaining, who will pick up Dao's work?
5 days for what? This doesn't have strings and it's not a feature. It's a cosmetic change that can be implemented later.
Really? I was under impression PL is new feature. Well, I'm glad I was wrong.
Well, technically, the "feature" is tab-specific loading progress indicators. That's already in, with the piechart.
Talked with drivers, this doesn't have to block b6 or the status bar landing since we already have visual per-tab progress via the pie-loaders.
blocking2.0: beta6+ → betaN+
Also, this doesn't look like it should block bug 578028, so removing that dependency.
No longer blocks: 574688, 578028
It blocks, because you can't move something that wasn't implemented yet. Until PL lands, bug 578028 is unfixable.
Attached patch updated patch (obsolete) — Splinter Review
I un-bitrotted the latest patch. I also updated the pinstripe theme to set the progress bar to be on top when tabs are on top. I haven't tested the other themes, so I'm not sure what they're looking like right now.
Attachment #474189 - Flags: ui-review?(limi)
Comment on attachment 474189 [details]
pinstripe with tabs on top

Just saw this in action, and it looks great. There may be a quick win from applying a CSS transition between the states to get a smooth movement of the progress bar, and we should also indicate the "Connecting" state as shorlander outlined it if we can.

App tabs seem to be broken too, but that should hopefully just be a matter of updating some values in how it calculates the width of a tab.

Very encouraging to see this working!
Attachment #474189 - Flags: ui-review?(limi) → ui-review+
Assignee: nobody → margaret.leibovic
Status: NEW → ASSIGNED
Blocks: 578028
Attached patch patch v2 (obsolete) — Splinter Review
Fixed problems with app tabs and panorama (I turned off the progress bar for app tabs for now). The progress bar needs a "connecting" state and some transition polish, but right now it works without breaking things.
Attachment #474186 - Attachment is obsolete: true
Attachment #474881 - Flags: review?(dao)
Comment on attachment 474881 [details] [diff] [review]
patch v2

There's little value in doing it this way now when we know it needs to change for app tabs. Bug 593967 should pave the way for making this work for all tabs by adding a xul:stack to the anonymous tab content.
Attachment #474881 - Flags: review?(dao) → review-
Depends on: 593967
(In reply to comment #187)
> Comment on attachment 474881 [details] [diff] [review]
> patch v2
> 
> There's little value in doing it this way now when we know it needs to change
> for app tabs. Bug 593967 should pave the way for making this work for all tabs
> by adding a xul:stack to the anonymous tab content.

Progress lines on App Tabs makes no sense given there size, you lose all ability to ascertain the progress on something so small. In that regards App Tabs should retain Pie usage.
(In reply to comment #187)
> Comment on attachment 474881 [details] [diff] [review]
> patch v2
> 
> There's little value in doing it this way now when we know it needs to change
> for app tabs. Bug 593967 should pave the way for making this work for all tabs
> by adding a xul:stack to the anonymous tab content.

is the only reason for r- because there are other changes to make in the future? 

this change is blocking beta6 blockers, so let's move it forward and make those changes later when it's necessary to do so. no progress lines on app tabs sounds like something we can survive a beta with.

unless you're getting bug 593967 landed in the next couple of hours...
(In reply to comment #189)

> this change is blocking beta6 blockers, so let's move it forward and make those
> changes later when it's necessary to do so. no progress lines on app tabs
> sounds like something we can survive a beta with.

If we want, I can reverse the dependency between this bug and bug 578028, ripping the css out of this patch to make a new patch to get a progress line in the location bar before worrying about the tabs.
(In reply to comment #190)
> (In reply to comment #189)
> 
> > this change is blocking beta6 blockers, so let's move it forward and make those
> > changes later when it's necessary to do so. no progress lines on app tabs
> > sounds like something we can survive a beta with.
> 
> If we want, I can reverse the dependency between this bug and bug 578028,
> ripping the css out of this patch to make a new patch to get a progress line in
> the location bar before worrying about the tabs.

hm, does that address Dao's concern, or just move the same code to a different bug?
(In reply to comment #191)

> hm, does that address Dao's concern, or just move the same code to a different
> bug?

It should address dao's concern about the tab layout and css selectors for the tabs. I would be taking the new css properties from this patch and using them for the urlbar progress bar. It would be kind of annoying to move the code around, but it's doable if that's the only way to land bug 578028.
Ok, that sounds fine to me then... outside of the annoying part ;) If you have the cycles, let's break the dependency in order to land the b6 blocker.
No longer blocks: 578028
I minused the patch not because there would be follow-up work to do, but because we'd have to re-implement it to a large part. Bug 593967 isn't more invasive than the current patch here, so we should just take it first and implement this properly.

Also, breaking up the dependency with bug 578028 is certainly a good idea.
Attached patch patch v3 (obsolete) — Splinter Review
Updated patch to use new tab binding, but now it depends on the patch for bug 578028.
Attachment #474881 - Attachment is obsolete: true
Attachment #475667 - Flags: ui-review?(shorlander)
Depends on: 578028
No longer depends on: 550825, 593967
Attachment #475667 - Flags: review?(dao)
Attachment #475667 - Flags: review?(gavin.sharp)
Attachment #475667 - Flags: review?(dolske)
Attachment #471789 - Attachment is obsolete: true
Comment on attachment 475679 [details] [diff] [review]
patch v4 (turned off progress bars for app tabs)

>+++ b/browser/base/content/tabbrowser.xml
...
>               if (this.mTotalProgress) {
>+                let value = Math.ceil(this.mTotalProgress * 100);
>+                this.mTab.setAttribute("progresspercent", value);
>+                
>                 const STATES = 8;
>                 let state = Math.ceil(STATES * this.mTotalProgress);
>                 if (state != this.mTab.getAttribute("progress")) {
>                   this.mTab.setAttribute("progress", state);
>                   this.mTab.removeAttribute("stalled");
>                   this._startStalledTimer();
>                 }
>               }

The block right below your change can be removed, since the 8-state pie throbber is gone now.

You could just unconditionally do the removeAttribute() and _startStalledTimer() calls, though I suppose that's a but unfortunate to be doing that so often [nsBrowserStatusFilter seems to filter this to 160ms, so it's not _too_ bad.]. The 8-state bit was essentially throttling itself, but I think it's wrong -- if you're fetching an enormous file, it could take a while to increment the state (aka percentage), even though it's most definitely not stalled.

Maybe just remove them entirely, since we're not actually using the |stalled| state yet.


>+++ b/browser/themes/*stripe/browser/browser.css

>+.tab-progress > .progress-bar:-moz-locale-dir(ltr),
>+.tab-progress > .progress-remainder:-moz-locale-dir(rtl) {
>+  -moz-border-radius-bottomleft: 3px;
>+}
>+
>+.tab-progress > .progress-bar:-moz-locale-dir(rtl),
>+.tab-progress > .progress-remainder:-moz-locale-dir(ltr) {
>+  -moz-border-radius-bottomright: 3px;


Is this the style used for the attachment 474189 [details] screenshot? The curved _top_ of the progress bar seems very odd, like it either needs to be wider (to the curve matches the tab's curve), or curved in the opposite direction.
(In reply to comment #197)
> >+++ b/browser/themes/*stripe/browser/browser.css
> 
> >+.tab-progress > .progress-bar:-moz-locale-dir(ltr),
> >+.tab-progress > .progress-remainder:-moz-locale-dir(rtl) {
> >+  -moz-border-radius-bottomleft: 3px;
> >+}
> >+
> >+.tab-progress > .progress-bar:-moz-locale-dir(rtl),
> >+.tab-progress > .progress-remainder:-moz-locale-dir(ltr) {
> >+  -moz-border-radius-bottomright: 3px;
> 
> 
> Is this the style used for the attachment 474189 [details] screenshot? The curved _top_
> of the progress bar seems very odd, like it either needs to be wider (to the
> curve matches the tab's curve), or curved in the opposite direction.

Yes, the progress bar is not supposed to have rounded edge, AFAIK. remove those, and it looks good.

(we can fix the styling in the polish phase, so let's not bikeshed on this part just yet. ;)
Blocks: 596812
Attached patch patch v5 (obsolete) — Splinter Review
I updated the patch so that it will apply, and I addressed comments from dolske and limi. However, the progress lines aren't showing up right now, and I'm not sure why. I just wanted to upload my latest patch before taking a break.
Attachment #475667 - Attachment is obsolete: true
Attachment #475679 - Attachment is obsolete: true
Attachment #475732 - Flags: review?(dao)
Attachment #475667 - Flags: ui-review?(shorlander)
Attachment #475667 - Flags: review?(gavin.sharp)
Attachment #475667 - Flags: review?(dolske)
Attachment #475667 - Flags: review?(dao)
Depends on: 550825
Depends on: 593967
(In reply to comment #196)
> (turned off progress bars for app tabs)

Why are you doing this?
Comment on attachment 475732 [details] [diff] [review]
patch v5

>--- a/browser/themes/gnomestripe/browser/browser.css
>+++ b/browser/themes/gnomestripe/browser/browser.css

>+.tab-progress-container {
>+  -moz-box-pack: end;
>+  margin-bottom: -3px;
>+}
>+
>+#tabbrowser-tabs[tabsontop="true"] > .tabbrowser-tab > .tab-stack > .tab-progress-container {
>+  -moz-box-pack: start;
>+  margin-top: -3px;
>+}

>--- a/browser/themes/winstripe/browser/browser.css
>+++ b/browser/themes/winstripe/browser/browser.css

>+.tab-progress-container {
>+  -moz-box-pack: end;
>+  margin-bottom: -3px;
>+}
>+
>+#tabbrowser-tabs[tabsontop="true"] > .tabbrowser-tab > .tab-stack > .tab-progress-container {
>+  -moz-box-pack: start;
>+  margin-top: -3px;
>+}

This looks wrong. The line should always be at the top edge except for tabs-on-bottom with pinstripe.

As far as I know pinned tabs are supposed to have the progress line, so I'm not sure why you're removing it. Still technical problems? Seems like you should keep the current indicator on pinned tabs for now if there's a reason not to have the progress line there.
Attachment #475732 - Flags: review?(dao) → review-
I see https://bugzilla.mozilla.org/show_bug.cgi?id=578028 has landed. how do we organize the progress line on tab top vs progress line at bottom of urlbar?
Attached patch patch v6 (obsolete) — Splinter Review
It turned out there was a problem with the binding, but the patch is working now.
Attachment #475732 - Attachment is obsolete: true
Attachment #475922 - Flags: ui-review?(shorlander)
(In reply to comment #201)
> As far as I know pinned tabs are supposed to have the progress line, so I'm not
> sure why you're removing it. Still technical problems?

There seems to be some technical issues, but apart from that, progress in app tabs is probably more distracting than helpful — you know that it's there, it's supposed to stick around, and be a constant presence.

The app tabs are getting quite busy with progress indicators and change notifications, so we might want to consider not having them for app tabs, as they are arguably less useful in the standard app use case.
Attachment #475922 - Flags: review?(dao)
(In reply to comment #205)
> (In reply to comment #201)
> > As far as I know pinned tabs are supposed to have the progress line, so I'm not
> > sure why you're removing it. Still technical problems?
> 
> There seems to be some technical issues, but apart from that, progress in app
> tabs is probably more distracting than helpful — you know that it's there, it's
> supposed to stick around, and be a constant presence.
> 
> The app tabs are getting quite busy with progress indicators and change
> notifications, so we might want to consider not having them for app tabs, as
> they are arguably less useful in the standard app use case.

I'm not sure I agree. The change notification should've been a blinking fav icon with a pie chart load indicator. That way all indications were in the same place and made best use of the limited space. Instead we've opted for something that looks more akin to a failure or warning notice on an App Tab than a friendly notification. Users shouldn't be made to guess if app tabs are working or not and especially in the initial load (more so given the persistance of app tabs) should be given an indicator at to whether there's life in them or not.
(In reply to comment #206)
> I'm not sure I agree. The change notification should've been a blinking fav
> icon with a pie chart load indicator.

Blinking/glowing is very distracting, and not a good approach in general.

> especially in the initial load (more so given the persistance of app
> tabs) should be given an indicator at to whether there's life in them or not.

The favicon itself is a good indicator of that.
Alex, why not to use pie chart inside App Tab's favicon? It would be grey and by progress it would fill it with color just like pie chart.
(In reply to comment #207)
> Blinking/glowing is very distracting, and not a good approach in general.
To be fair, distracting is exactly what you want from a notification. Blink it
X times then give the status icon a static (not blinking) glow.


> The favicon itself is a good indicator of that.
It gives no indication of progress. Plus not all sites, even if they should,
have favicons.
Attached patch patch v7 (obsolete) — Splinter Review
Fixed tabs-on-bottom and margin styling for linux/windows. Added fadein effect to progress line.
Attachment #475922 - Attachment is obsolete: true
Attachment #475950 - Flags: ui-review?(shorlander)
Attachment #475950 - Flags: review?(dao)
Attachment #475922 - Flags: ui-review?(shorlander)
Attachment #475922 - Flags: review?(dao)
1. Can you make proper styling in this patch?
2. Can you make PL glow?
Attached patch patch v8 (obsolete) — Splinter Review
Fixed min-width problem.
Attachment #475950 - Attachment is obsolete: true
Attachment #475961 - Flags: ui-review?(shorlander)
Attachment #475961 - Flags: review?(dao)
Attachment #475950 - Flags: ui-review?(shorlander)
Attachment #475950 - Flags: review?(dao)
Attachment #475961 - Flags: ui-review?(shorlander) → ui-review+
Comment on attachment 475961 [details] [diff] [review]
patch v8

>+.tabbrowser-tab[pinned] > .tab-stack > .tab-progress-container,
>+.tab-progress-container[selected="true"] {
>+  display: none;
>+}
>+
>+.tab-progress {
>+  -moz-binding: url("chrome://global/content/bindings/progressmeter.xml#progressmeter") !important;
>+  display: none;
>+  margin: 0;
>+}
>+
>+.tab-progress[busy] {
>+  display: -moz-box;
>+}

How about:

.tab-progress:not([busy]),
.tab-progress:not([selected]) {
  display: none;
}

>+.tab-progress {
>+  min-width: 0px;
>+}

Seems like this should be in tabbrowser.css.

>+.tab-progress-container {
>+  -moz-box-pack: start;
>+}

... and this too (pinstripe would override it for tabs on bottom).

Would be easier for me to r+ this if removing progress indicators from pinned tabs wasn't crammed into this bug.
I fixed the css and put progress lines on the app tabs. From a technical perspective, fixing the min-width issue fixed the progress lines for the app tabs, but from a UI design perspective, I think it's up to limi and shorlander to decide whether or not they should be there.
Attachment #475961 - Attachment is obsolete: true
Attachment #476008 - Flags: ui-review?(shorlander)
Attachment #476008 - Flags: review?(dao)
Attachment #475961 - Flags: review?(dao)
Comment on attachment 476008 [details] [diff] [review]
patch v9 (with progress line for app tabs)

It doesn't convey much information outside of "there's something going on", but I think it's the best we can do for now. None of the other suggested options make it better, so I'd say we go with this one.
Attachment #476008 - Flags: ui-review?(shorlander) → ui-review+
Comment on attachment 476008 [details] [diff] [review]
patch v9 (with progress line for app tabs)

r=me on the interdiff between this and v8.
Attachment #476008 - Flags: review+
The work here is great but I was wonder if it possible to "integrate" the progress line with the curvature of each end of the tab?  As it stands now, it's just sitting at the top of the tab with a blunt start and stop.  It appears as if it is out of place.  I've attached a screenshot that hopefully indicates what I'm talking about.  :-)

~B
Blocks: 597307
(In reply to comment #217)
> The work here is great but I was wonder if it possible to "integrate" the
> progress line with the curvature of each end of the tab?  As it stands now,
> it's just sitting at the top of the tab with a blunt start and stop.  It
> appears as if it is out of place.  I've attached a screenshot that hopefully
> indicates what I'm talking about.  :-)

We're going to be working on polishing the progress lines in 597307. Shorlander
should be posting mock-ups there with a more complete design.
http://hg.mozilla.org/mozilla-central/rev/191d6bb957b0
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
This looks really cool. Thanks for getting it on. One question: The mockups had Green progress lines... this one is Blue; so is this the final version in terms of color? Since the overall Firefox theme is bluish, green progress bars will stand out better I think.

Should I file a separate bug or will it be taken care of during polish anyways?
Comment on attachment 476008 [details] [diff] [review]
patch v9 (with progress line for app tabs)

Gavin reviewed only the interdiff, so this basically landed without formal review. Luckily I was almost done. I address what I would have said here: http://hg.mozilla.org/mozilla-central/rev/c69ba7f85675
Attachment #476008 - Flags: review?(dao) → review+
Progress lines looks awful on app tabs. And i'm not speaking about the lack of polishing. I think we should use pie charts in app tabs.
App tabs are meant to contain web apps. The initial start is indicated just fine just by the fact that the favicon is shown (IMHO it is fair to say that every web app has a favicon). After the initial load, web apps are not really supposed to require *full* page refreshes which is the only thing the progress indicator is used for? So, I don't see the point of having a separate indicator for app tabs.
(In reply to comment #224)
> App tabs are meant to contain web apps. The initial start is indicated just
> fine just by the fact that the favicon is shown (IMHO it is fair to say that
> every web app has a favicon). After the initial load, web apps are not really
> supposed to require *full* page refreshes which is the only thing the progress
> indicator is used for? So, I don't see the point of having a separate indicator
> for app tabs.

You should have a look to this http://groups.google.com/group/mozilla.dev.usability/browse_thread/thread/eb581c44da4b627e?pli=1 ;-)
(In reply to comment #224)
> After the initial load, web apps are not really
> supposed to require *full* page refreshes

Very much depends on the application. I pinned iGoogle which reloads periodically and a forum where I want to stay on the domain but not on a certain page.
No longer blocks: 597307
Depends on: 597307
Depends on: 597414
Depends on: 597422
Component: Theme → Tabbed Browser
QA Contact: theme → tabbed.browser
(In reply to comment #221)
> This looks really cool. Thanks for getting it on. One question: The mockups had
> Green progress lines... this one is Blue; so is this the final version in terms
> of color? Since the overall Firefox theme is bluish, green progress bars will
> stand out better I think.
> 
> Should I file a separate bug or will it be taken care of during polish anyways?
usrChrome.css

.tab-progress > .progress-bar,#urlbar-progress > .progress-bar
{background-image: -moz-linear-gradient(left, rgba(255, 255, 0, 0.5),
                                               rgba(255, 255, 0, 0.7),
                                               rgba(255, 255, 0, 0.95)) !important;}
Verified fixed

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre(In reply to comment #221)
> This looks really cool. Thanks for getting it on. One question: The mockups had
> Green progress lines... this one is Blue; so is this the final version in terms
> of color? Since the overall Firefox theme is bluish, green progress bars will
> stand out better I think.
> 
> Should I file a separate bug or will it be taken care of during polish anyways?

Please file a new bug and mark it blocking/depends (I always screw those up) on this bug and bug 597307 (the polish tracking bug).
Status: RESOLVED → VERIFIED
Target Milestone: --- → Firefox 4.0b7
(In reply to comment #221)
> This looks really cool. Thanks for getting it on. One question: The mockups had
> Green progress lines... this one is Blue; so is this the final version in terms
> of color? Since the overall Firefox theme is bluish, green progress bars will
> stand out better I think.
> 
> Should I file a separate bug or will it be taken care of during polish anyways?

I Filed bug 597592 against polish bug 597307.
Depends on: 597665
Blocks: 597673
No longer blocks: 597673
Depends on: 597673
No longer depends on: 597665
Depends on: 600081
This feature is highly obtrusive and highly persistent. The progress bar is a laser light show, it appears on the tabs and the location bar -- a large portion of the screen, and it is displayed when pages are loading -- very frequently.

1. Have you consulted with experts in the field to determine the likelihood of the design posing a health risk? The National Society for Epilepsy estimates 1,500,000 to 2,500,000 people worldwide suffer from photosensitive epilepsy.
http://www.epilepsysociety.org.uk/AboutEpilepsy/Whatisepilepsy/Epilepsy-didyouknow

I am aware that flickering lights such as strobe lights are generally what induce epileptic seizures, and thin progress bars do not fit that description, however pulsating, shiny and ubiquitous they may be. Still, I would like to know that the design was vetted by epilepsy experts.

2. Will there be an easily-accessible option to turn off this feature? Not providing such an option would contradict your accessibility statement:
"Firefox does not use animation in its user interface."
http://www.mozilla.com/en-US/firefox/vpat-3.html
This design is radically more visible to the point of being impossible to overlook. It is in an entirely different league from the diminutive status bar progress block in Firefox 3.6.

Distantly related: bug 438848
Are you serious? Flickering... ?! There is no flickering, only moving white element in connecting state. And the same effect is using WinVista+, in Win7 you can even see it in Superbar. So I hope you sent the same beneficial message to Microsoft as well.
(In reply to comment #230)
> This feature is highly obtrusive and highly persistent. The progress bar is a
> laser light show, it appears on the tabs and the location bar -- a large
> portion of the screen, and it is displayed when pages are loading -- very
> frequently.
> 
> 1. Have you consulted with experts in the field to determine the likelihood of
> the design posing a health risk? The National Society for Epilepsy estimates
> 1,500,000 to 2,500,000 people worldwide suffer from photosensitive epilepsy.
> http://www.epilepsysociety.org.uk/AboutEpilepsy/Whatisepilepsy/Epilepsy-didyouknow
> 
> I am aware that flickering lights such as strobe lights are generally what
> induce epileptic seizures, and thin progress bars do not fit that description,
> however pulsating, shiny and ubiquitous they may be. Still, I would like to
> know that the design was vetted by epilepsy experts.
> 
> 2. Will there be an easily-accessible option to turn off this feature? Not
> providing such an option would contradict your accessibility statement:
> "Firefox does not use animation in its user interface."
> http://www.mozilla.com/en-US/firefox/vpat-3.html
> This design is radically more visible to the point of being impossible to
> overlook. It is in an entirely different league from the diminutive status bar
> progress block in Firefox 3.6.
> 
> Distantly related: bug 438848

Are you using some weird Theme that makes the progress line flicker?
Certainly NO flickering with the default Theme! 
Actually what i see is just a thin blue line filling in till the loading is complete and then disappears, ever so thin sometimes I can hardly see it!
As for the progress lines on the tabs and app tabs, I can see them even less!
Depends on: 601480
This is actually a very serious consideration, especially considering the global nature of our product.  I've filed bug 601546 to provide users with a single control point for all of our UI animation (not just progress lines), and we may need to either block on addressing it, or update our documentation to warn users that we have some UI animation until we can give them control over it.
Blocks: 601780
Flags: in-litmus?
Is this the core bug report responsible for removing the status bar?
(In reply to comment #234)
> Is this the core bug report responsible for removing the status bar?

Probably bug 574688.
You need to log in before you can comment on or make changes to this bug.