Closed Bug 578028 Opened 14 years ago Closed 14 years ago

Move Progress Line to Location Bar, if loading tab is active

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: Terepin, Assigned: Margaret)

References

(Depends on 1 open bug)

Details

Attachments

(3 files, 8 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; sk; rv:2.0b2pre) Gecko/20100712 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; sk; rv:2.0b2pre) Gecko/20100712 Minefield/4.0b2pre

Current patch for PL will display lines on all loading tabs. When user clicks on one of them, tab will become active and therefore PL should move to Location Bar.

Someone from UX should attach mockup, because the one from wiki was deleted.

Reproducible: Always
Blocks: 578025
blocking2.0: --- → ?
Depends on: 544818
OS: Windows 7 → All
Hardware: x86 → All
Version: unspecified → Trunk
No longer blocks: 578025
Blocks: 578025
Not sure if we already have a bug filed on this or not, but shorlander and dao would know.
can't both the active tab and the location bar have PL?
What for?
It will give a more uniform look as all tabs have PL. But doing 2 PL in the active tab will consume more system resources. It may not be worth doing it. 

Peter, PL in the location bar is implemented just like they are in the tabs? 
Or are they trying to do it like how Microsoft did it in Win 7 Window Explorer?
It will be just like in tabs. PL will be inside location bar at the bottom.
Why do we really need two? Is a location bar PL really needed for anything other than with the tab bar hidden? The duplicate favicon is being removed to reduce unhelpful redundancy so I don't see the point in adding a duplicate progress indicator.
We are going to move the PL, not copy, hence no duplucation.
It's duplication of concept not necessarily two at the same time, unless suggestions to do so are done. What I mean is that it feels like an unnecessary break in consistency to move it down when there's no real disadvantage to always having it on the tab and there is the advantage of having the progress bar always be in the same relative place for every tab.
I'll give you two main resons why to do this (more reason will give you someone from the UX team):
1. PL are on background tabs because it is tab that is loading and you are looking at tabs.
2. But when you click on some of those tabs, you are displaying the page, you are looking at page, your loading the page and anything page-related is ine Location Bar. Tab has no longer nothing to do with it, because even favicon will be showed before the page itslef.
The foreground tab is still a tab. If you think of a full tab as a 2D layer, and the act of switching tabs is to merely pick who's on top, then the tab tops shouldn't change when switching tabs. It would break the tab metaphor, which is just another way for me to argue that it would break consistency.
There's also the effect of a location bar PL on ctrl+tabbing through a bunch of loading tabs. There would also be a lot more changing in the location bar area; a bunch of tabbing would switch the location bar PL size around a lot, whilst this wouldn't affect the tab PLs. Yes, the location bar is expected to change around, but a rapidly changing green glowing thing is more noticeable and there is no difference between one green line and another.

Seeing as performance was brought up above, there's also the extra (very) small performance hit on changing tabs (show big PL, hide current small PL, show prev small PL). Might not be enough to care about, but I guess it's worth mentioning.
Not just that, moving the PL to the location bar will show it in more detail. But, yeah, there are still slight performance issues.
Shorlander - this sounds like an RFE - not blocking theme work, is that right? If not, if this is essential to the theme, please re-nom.
blocking2.0: ? → -
Blocks: 574688
(In reply to comment #2)
> can't both the active tab and the location bar have PL?

yeah I think a preference in about:config should be created for that.
browser.tabs.showProgressLine = "0" (default value) - PL shown for location bar only.
browser.tabs.showProgressLine = "1" - PL shown above tab.
browser.tabs.showProgressLine = "2" - PL shown in both places.
What is the *practical* reason for having PL in both places at the same time?
(In reply to comment #15)
> What is the *practical* reason for having PL in both places at the same time?

Actually there is no practical use, I think, it is just not hard to implement, so why not? If any geek wants it that way - let him do it. A thousand more of satisfied users.

New idea: change the color for active tab from green to orange, for example. Than a user will distinguish an active tab easier.
Different color is covered in different bug.
(In reply to comment #14)
> yeah I think a preference in about:config should be created for that.

No. We don't need any extra complexity for that. We should pick one that's best and stick with it. If a user really really want's it otherwise, use an addon.
Blocks: 586718
Status: UNCONFIRMED → NEW
Ever confirmed: true
There is another good reason for this, if the user has the tab bar set to auto-hide, then the PL won't be visible if on the tab.
This is required for bug 586718 which seemingly is required for the new extensions bar that will replace the status bar.

Kind of hard to implement this without a design, though. Is that forthcoming?
blocking2.0: - → beta5+
As per many conversations that I've had on IRC, feels like we need to represent three states:

1 - Connecting: the browser is looking up the website and trying to connect to the server

2 - Loading: the browser is getting data from the server and loading the website

3 - Loaded: the static resources on the website are fully loaded; we should show this even if there are XHR or asynchronous loads still outstanding
(In reply to comment #20)
> This is required for bug 586718 which seemingly is required for the new
> extensions bar that will replace the status bar.
> 
> Kind of hard to implement this without a design, though. Is that forthcoming?

Isn't bug 544818 what's really needed for that? This here is just about placement for the progress line for the current tab. Any indications would be the same, just in a different place.
blocking2.0: beta5+ → betaN+
Attached image Progress Bar States
(In reply to comment #20)
> Kind of hard to implement this without a design, though. Is that forthcoming?

(In reply to comment #21)
> 1 - Connecting: the browser is looking up the website and trying to connect to
> the server
> 
> 2 - Loading: the browser is getting data from the server and loading the
> website
> 
> 3 - Loaded: the static resources on the website are fully loaded; we should
> show this even if there are XHR or asynchronous loads still outstanding

This image illustrates the suggested UI for representing connecting and loading a website using a progress bar.

- Connecting: Grey light indicator traveling from left to right to represent connecting
- Loading: Green progress bar used for initial page loading
- Loaded: Grey progress bar and stop icon while the page is still downloading

I kept everything but the loading progress bar grey and very neutral to make sure it was as distraction free as possible.

I also created a movie/animation to show how it would work:

http://www.stephenhorlander.com/pages/progress-bar-line-mockup/progress-bar-line-states.html
Fantastic!
But I still think PL needs glow.
moving to beta6+, since it blocks removal of the status bar (bug 574688).
blocking2.0: betaN+ → beta6+
PL Need glow or be made taller, or else it is hard for the users to notice PL.
I know it is not the right bug to ask this question, but I simply cannot find the correct bug. Is the status bar still going to be replaced by a addon bar?
(In reply to comment #27)
> I know it is not the right bug to ask this question, but I simply cannot find
> the correct bug. Is the status bar still going to be replaced by a addon bar?

That is bug 574688
Assignee: nobody → adw
No longer depends on: 544818
Attached patch WIP (obsolete) — Splinter Review
Still need to fix:
-Give progress bar its own space so that it doesn't make the urlbar contents jump up and down when it appears/hides
-Update location bar progress bar when active tab changes (I noticed this was buggy)
-Add "connecting" state and css transitions (should be resolved by bug 544818)
Assignee: adw → margaret.leibovic
Status: NEW → ASSIGNED
Attached image WIP screenshot
Flags: in-litmus?
Depends on: 544818
Hi, sorry if I'm posting on the wrong place but I'm using Firefox 4 beta and I would like to test these, and some other, features I've seen in here. I noticed that there are some patches, but how can I apply them on my version of Firefox? Is there any place that teaches me how to use it? Or the nightly builds already has them?

Thanks in advance, hope it's not too bad to post a question like this in here.
(In reply to comment #31)
> Hi, sorry if I'm posting on the wrong place but I'm using Firefox 4 beta and I
> would like to test these, and some other, features I've seen in here. I noticed
> that there are some patches, but how can I apply them on my version of Firefox?
> Is there any place that teaches me how to use it? Or the nightly builds already
> has them?
> 
> Thanks in advance, hope it's not too bad to post a question like this in here.

you'd have to build a build yourself or wait until a tryserver build is produced with this patch or until the patch is checked in and then download a nightly build.
Attached patch patch (obsolete) — Splinter Review
I'm not sure how this looks on Linux and Windows, but if the styling for bug 544818 works, this should hopefully work.
Attachment #474290 - Attachment is obsolete: true
Attachment #474885 - Flags: review?(dao)
Dao: if you don't have time for this review, you can set the request on me.
We have a problem because the patch here builds on the patch in bug 544818, but dao doesn't want to land that until the patch for bug 593967 is done. 

I built on the patch in bug 544818 so that I could re-use the css. However, I could just rip that out and write a fresh patch for this bug. Should I do that so that we can get rid of the dependency?
Attached patch patch v2 (obsolete) — Splinter Review
This patch doesn't depend on bug 544818 anymore. It needs to be tested on windows/linux and could use more polish, but I wanted to get it out for review quickly.
Attachment #474885 - Attachment is obsolete: true
Attachment #475206 - Flags: review?(mano)
Attachment #474885 - Flags: review?(dao)
No longer depends on: 544818
Attachment #475206 - Attachment is patch: true
Attachment #475206 - Attachment mime type: application/octet-stream → text/plain
(In reply to comment #36)

> This patch doesn't depend on bug 544818 anymore. It needs to be tested on
> windows/linux and could use more polish, but I wanted to get it out for review
> quickly.

I just tested it on Windows 7, and it has some of the same polish issues as the Mac theme, but it works.
You should take a look at bug 587908, there will be conflicts.
Comment on attachment 475206 [details] [diff] [review]
patch v2

drive-by comments...

>-#urlbar:-moz-locale-dir(rtl) > .autocomplete-textbox-container > .textbox-input-box {
>+#urlbar:-moz-locale-dir(rtl) > .urlbar-contents > .autocomplete-textbox-container > .textbox-input-box {
>   direction: rtl;
> }

This should be .urlbar-contents:-moz-locale-dir(rtl) > .autocomplete-textbox-container > .textbox-input-box
 at least. If you follow bug 587908 it would be something like .urlbar-textbox-input-box:-moz-locale-dir(rtl).

>+        <xul:progressmeter class="urlbar-progress" id="urlbar-progress" mode="normal"/>

Anonymous nodes shouldn't have ids. I think you actually don't use this one...

>+  -moz-border-radius-bottomleft: 3px;

-moz-border-radius is dead, use border-bottom-left-radius instead.
Attachment #475206 - Flags: feedback+
Attached patch patch v3 (obsolete) — Splinter Review
Needs to be tested on linux/windows.
Attachment #475206 - Attachment is obsolete: true
Attachment #475620 - Attachment is obsolete: true
Attachment #475623 - Flags: review?(mano)
Attachment #475206 - Flags: review?(mano)
(In reply to comment #39)

> >+        <xul:progressmeter class="urlbar-progress" id="urlbar-progress" mode="normal"/>
> 
> Anonymous nodes shouldn't have ids. I think you actually don't use this one...

It's used by get statusMeter () in browser.js. How should I change that to have it still work if I get rid of the id?
1. I cannot test on windows and linux. Someone else will have to do that.
2. See dao's comments

> /* For results that are actions, their description text is shown instead of
>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js
>--- a/browser/base/content/browser.js
>+++ b/browser/base/content/browser.js
 
>   get statusMeter () {
>     delete this.statusMeter;
>-    return this.statusMeter = document.getElementById("statusbar-icon");
>+    return this.statusMeter = document.getElementById("urlbar-progress");

As Dao said, you cannot use id within a binding.

The small fix is to use anonid.  The better fix is to use attribute inheritance (set a "progress" attribute on the location bar and inherit it as "value" for the progressmeter).

>diff --git a/browser/base/content/urlbarBindings.xml b/browser/base/content/urlbarBindings.xml
>--- a/browser/base/content/urlbarBindings.xml
>+++ b/browser/base/content/urlbarBindings.xml
 
> <bindings id="urlbarBindings" xmlns="http://www.mozilla.org/xbl"
>+          xmlns:html="http://www.w3.org/1999/xhtml"
>           xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
>           xmlns:xbl="http://www.mozilla.org/xbl">
> 
>   <binding id="urlbar" extends="chrome://global/content/bindings/autocomplete.xml#autocomplete">

This cannot be review because the binding has changed much.

>diff --git a/browser/themes/*stripe/browser/browser.css b/browser/themes/*stripe/browser/browser.css
>@@ -907,16 +907,82 @@ toolbar[iconsize="small"] #zoom-in-butto
> #PopupAutoComplete:-moz-locale-dir(rtl) > tree > treerows {
>   direction: rtl;
> }
> 
> #PopupAutoComplete .autocomplete-treebody {
>   direction: ltr;
> }
> 
>+/* Urlbar Progress */
>+
>+.urlbar-progress-container {
>+  -moz-box-pack: end;
>+  margin-bottom: -3px;

Why is a negative margin needed here?

>+.urlbar-progress {
>+  -moz-appearance: none;
>+  height: 3px;
>+  border: 0;

>+  min-width: 0;
>+  min-height: 0;
Why?


Not much to say otherwise.  Indeed, it needs some polish, but it's OK at this stage.  I'm setting feedback+ rather than review+ because I would like to double check the final binding changes.
Oh, I missed the new patch...
Comment on attachment 475623 [details] [diff] [review]
patch v3

The comments still stand.
Attachment #475623 - Flags: review?(mano) → feedback+
Attached patch patch v4 (obsolete) — Splinter Review
Fixed id issue.
Attachment #475623 - Attachment is obsolete: true
Attachment #475638 - Flags: ui-review?(shorlander)
Attachment #475638 - Flags: review?(mano)
(In reply to comment #43)
> 1. I cannot test on windows and linux. Someone else will have to do that.
> 2. See dao's comments
> 
> > /* For results that are actions, their description text is shown instead of
> >diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js
> >--- a/browser/base/content/browser.js
> >+++ b/browser/base/content/browser.js
> 
> >   get statusMeter () {
> >     delete this.statusMeter;
> >-    return this.statusMeter = document.getElementById("statusbar-icon");
> >+    return this.statusMeter = document.getElementById("urlbar-progress");
> 
> As Dao said, you cannot use id within a binding.
> 
> The small fix is to use anonid.  The better fix is to use attribute inheritance
> (set a "progress" attribute on the location bar and inherit it as "value" for
> the progressmeter).

To fix this I just put the progressmeter element in browser.xul, so that I could still re-use the code that made the status bar progressmeter work.

> >+/* Urlbar Progress */
> >+
> >+.urlbar-progress-container {
> >+  -moz-box-pack: end;
> >+  margin-bottom: -3px;
> 
> Why is a negative margin needed here?

The negative margin makes the progress bar overlap the outside of the urlbar, which is what shorlander indicated in his mockups. I've also updated this css in my latest patch, anyway.

> >+.urlbar-progress {
> >+  -moz-appearance: none;
> >+  height: 3px;
> >+  border: 0;
> 
> >+  min-width: 0;
> >+  min-height: 0;
> Why?

To be honest, I was copying css from the original patch for Bug 544818, but this doesn't seem to be needed, so I'll get rid of it. I'll also do some css cleanup while I'm at it.
1. How do you move the element to browser.xul?
2. I wonder if a stack should be used for this overlapping effect.
Attached patch patch v5 (obsolete) — Splinter Review
Cleaned up css.
Attachment #475638 - Attachment is obsolete: true
Attachment #475638 - Flags: ui-review?(shorlander)
Attachment #475638 - Flags: review?(mano)
Attachment #475652 - Flags: review?(dolske)
Blocks: 544818
Comment on attachment 475652 [details] [diff] [review]
patch v5

r=mano. The css will need further cleanup, but that's good to go.
Attachment #475652 - Flags: review?(dolske) → review+
Attached patch patch v6 (obsolete) — Splinter Review
Fixed progress bar height problem for linux/windows, and fixed history dropmarker padding.
Attachment #475652 - Attachment is obsolete: true
Comment on attachment 475704 [details] [diff] [review]
patch v6

Minor issues testing on Linux that can be dealt with in followups:
- seems to cause the dropmarker to change position in RTL

>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js

>         else
>-          this.statusMeter.parentNode.collapsed = false;
>+        	this.statusMeter.collapsed = false;

stray tab here

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

>+.urlbar-progress-container {
>+  -moz-box-pack: end;

Use pack="end" on the XUL element instead. (applies to all themes)

>+#urlbar-progress[busy][stalled][value="0"] {
>+  /* TODO: add connecting state */
>+}

What's "connecting state"? File a followup and cite bug # here? (applies to all themes)

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

>+#urlbar-progress {

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

I think this belongs in the content CSS.
Attachment #475704 - Flags: review+
Blocks: 596812
Attached patch patch v7Splinter Review
Attachment #475704 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/rev/22c4d4151710
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Depends on: 596867
Depends on: 596868
Due to this fading out at the business end (far right), I'm unable to ascertain just how much longer there is to go to a page fully loads. Can we have a hard edge at the right and perhaps move the gradient to the left if it had to exist?
I don't think PL should be moved to location bar.
1.) It's inconsistent. I have to now look in two places for progress. URL bar for current tab and the tab bar for other tabs. You should have it solely in tab bar so a user can get a quick glance at progress for all his tabs. There shouldn't be a usability issue since its pretty noticeable which tab is highlighted as active anyways. For example, when I was using the Tab Progress Bar extension (which uses the same "move to location bar" idea), I always looked at active tab for progress before correcting myself and looking back at location bar.

2.) Its distracting because the PL changes the shape of the location bar everytime something loads.
Use add-on as before.
Margaret, current PL is only placeholder, am I correct?
I find this line to be so thin that I barely notice it. I also find it difficult to see where the progress is at the moment. It is just a differnt shade of blue. 

I personally prefer the old pie chart.
Pie charts will replace by progress lines on all tabs, and will be on the top of the tabs. Check attachment 474291 [details] !
(In reply to comment #57)
> Use add-on as before.

The addon behaves the same way as you're trying to implement it. It moves progress to location bar and leaves active tab PL blank.

It's a real distraction, especially since the location bar's long length makes it difficult to see total progress.
Verified fixed.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100916
Firefox/4.0b7pre

Please file any followups in separate bugs!
Status: RESOLVED → VERIFIED
Is there a reason blue got implemented instead of the green in the mockup (besides it matching the default theme)?
Depends on: 597277
Blocks: 597307
(In reply to comment #59)
> I find this line to be so thin that I barely notice it. I also find it
> difficult to see where the progress is at the moment. It is just a differnt
> shade of blue. 
> 

I think its barely noticeable too. Especially with the transparency in windows 7. All the stuff from other windows makes it hard to see the line. In firefox 3.6 I have something similar with fission which changed the background colour of the whole location bar. I think its a lot easier to see the progress, and much more noticeable. 

(In reply to comment #56)
> There shouldn't be a usability issue since its pretty noticeable which tab is
> highlighted as active anyways. For example, when I was using the Tab Progress
> Bar extension (which uses the same "move to location bar" idea), I always
> looked at active tab for progress before correcting myself and looking back at
> location bar.

I disagree. If you have a number of tabs pile up its often hard to find which is the active.
No longer blocks: 597307
Depends on: 597307
(In reply to comment #64)
> (In reply to comment #56)
> > There shouldn't be a usability issue since its pretty noticeable which tab is
> > highlighted as active anyways.
> 
> I disagree. If you have a number of tabs pile up its often hard to find which
> is the active.

I initially was arguing against this bug in favor of progress lines only on tabs, and not a separate one for the location bar for the current tab (i.e. don't have duplicate indicator concepts). This argument, that moving it makes the currently selected tab more apparent, plus the fact that more indicators are being added to the way this bar works and its big size here helps that, has swayed my opinion. I think this is going to come out looking and working really great now. :)
Depends on: 597421
Component: General → Location Bar
QA Contact: general → location.bar
(In reply to comment #64)
> I disagree. If you have a number of tabs pile up its often hard to find which
> is the active.

Active tab is highlighted in a completely different color. It's really easy to spot. You just scan the tab bar. I just feel its inconsistent having to look in two separate places. Originally, progress was only showed in statusbar (one location), then progress was shown in tab bar using pie charts (still one location). Now we have to keep in mind that checking progress for active tab is ONLY on url bar, and progress for background tabs is ONLY in tab bar. It's confusing and unintuitive.
(In reply to comment #66)
> [...] Now we have to keep in mind that checking progress for active tab is
> ONLY on url bar, and progress for background tabs is ONLY in tab bar. It's
> confusing and unintuitive.

I tend to agree with this.  I wouldn't mind having it in *both* places, since it's definitely nice having the extra length of the location bar.  However, moving it around depending on whether or not you're in a particular tab state seems a bit...weird.
Having this feature on for a bit, I think the new bar should not go under the proxy button. It seems too busy, and the colors are often not in harmony.
(In reply to comment #63)
> Is there a reason blue got implemented instead of the green in the mockup
> (besides it matching the default theme)?

Filed bug 597592
No longer depends on: 596868
Litmus testcase added:
https://litmus.mozilla.org/show_test.cgi?id=12904
Flags: in-litmus? → in-litmus+
I know that the status of this bug is fixed but i would also prefer having only one kind of indicator : the progress bar on top of tabs (as long as tabs are displayed)

Of course if the tab bar is not shown (only one tab and "Always show the tab bar" unticked) the indicator should move to the url bar

Having the progress bar on tabs for background tabs and on url bar for foreground tab leads to useless complexity from my user point of view

BTW Robert O'Callahan seems to agree with that (see http://margaret.mit.edu/2010/09/a-month-at-mozilla/#comment-66 )
(In reply to comment #71)
> I know that the status of this bug is fixed but i would also prefer having only
> one kind of indicator : the progress bar on top of tabs (as long as tabs are
> displayed)
> 
> Of course if the tab bar is not shown (only one tab and "Always show the tab
> bar" unticked) the indicator should move to the url bar
> 
> Having the progress bar on tabs for background tabs and on url bar for
> foreground tab leads to useless complexity from my user point of view
> 
> BTW Robert O'Callahan seems to agree with that (see
> http://margaret.mit.edu/2010/09/a-month-at-mozilla/#comment-66 )

See comment 6 - 11. See also bug 597971 suggesting both places.
I have just tried this in the latest beta/trunk and it looks/feels ABSOLUTELY HORRIBLE. It makes the location UI look like someone has failed to polish the borders. It feels like a little worm slowly invading my browser. It's absolutely terrible. 

For heaven's sake if you really MUST take the two elements of the status bar that really cannot be replaced in a decent way, in this manic ludicrous desire to remove the status bar, at least do it sensibly: make the progress indicator the whole background of the location bar. It's been done many times before. Some other browser already does it, so your copycat design choices have a precedent.

Damn this is awful.

Give me back my status bar progress indicator! It's be a great solution for 15 years, which smart **** all of a sudden thinks it's not important? Talk about changing things to justify your existence.

* Make the old status bar indicator a Customise pallete option
* Make the RSS discovery icon a Customise Pallete option
* Make the old school menu a Customise Pallete option

No stuffing about, just do it!
Let's see:

(In reply to comment #73)
> ABSOLUTELY HORRIBLE. ... failed to polish...
> absolutely terrible. 
> For heaven's sake... manic ludicrous desire... copycat design choices ...
> Damn this is awful.

Followed by:

> No stuffing about, just do it!

I'm not sure if the appropriately rude retort is supposed to be "lol." or "*plonk*" but suffice it to say that nothing about this comment shows even a basic grasp of polite communication much less respect for the feelings of the human beings who work very hard to make Firefox every day.

It's unambiguous that you disagree with this change. Neat. It should be equally unambiguous to you, though, that your attitude in this bug is worse than impotent, it is offensive. No one here is paid to take your abuse, and they most certainly don't jump to your commands. You want to help? Fix a bug. In the meantime, take the sanctimonious petulance somewhere far, far away from here.
See the dependencies, it's not polished yet! 

Status bar will be removed and replaced with addons bar very soon. Bug 574688

I'm sure somebody will write an addon to put progress indicator into addons bar.

RSS discovery button: Bug 596731

Old school menu -> right click navbar -> tick Menu bar

Anyway, your style is horrible! You cant order the devs to do things especially in that tone. And you should get line on things before you comment. Stop spamming this bug, discuss this in forums.
(In reply to comment #73)
> No stuffing about, just do it!

Will do, just after I put my foot into your face...
Depends on: 599342
Depends on: 600081
No longer depends on: 597421
Depends on: 605409
You need to log in before you can comment on or make changes to this bug.