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

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[Peter Henkel [:Terepin]]

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

Comment 1

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

Not sure if we already have a bug filed on this or not, but shorlander and dao would know.

Comment 2

[Tan Wei Lin Jason [:Ryuji]]

can't both the active tab and the location bar have PL?

Comment 3

[Peter Henkel [:Terepin]]

What for?

Comment 4

[Tan Wei Lin Jason [:Ryuji]]

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?

Comment 5

[Peter Henkel [:Terepin]]

It will be just like in tabs. PL will be inside location bar at the bottom.

Comment 6

[Dave Garrett]

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.

Comment 7

[Peter Henkel [:Terepin]]

We are going to move the PL, not copy, hence no duplucation.

Comment 8

[Dave Garrett]

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.

Comment 9

[Peter Henkel [:Terepin]]

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.

Comment 10

[Dave Garrett]

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.

Comment 11

[Dave Garrett]

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.

Comment 12

[David Vo [:auscompgeek]]

Not just that, moving the PL to the location bar will show it in more detail. But, yeah, there are still slight performance issues.

Comment 13

[Johnathan Nightingale [:johnath]]

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.

Comment 14

[Please Ignore This Troll (Account Disabled)]

(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.

Comment 15

[Peter Henkel [:Terepin]]

What is the *practical* reason for having PL in both places at the same time?

Comment 16

[Please Ignore This Troll (Account Disabled)]

(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.

Comment 17

[Peter Henkel [:Terepin]]

Different color is covered in different bug.

Comment 18

[Dave Garrett]

(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.

Comment 19

[David Vo [:auscompgeek]]

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.

Comment 20

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

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?

Comment 21

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

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

Comment 22

[Dave Garrett]

(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.

Comment 23

[Stephen Horlander [:shorlander]]

Attachment: 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

Comment 24

[Peter Henkel [:Terepin]]

Fantastic!
But I still think PL needs glow.

Comment 25

[Dietrich Ayala (:dietrich)]

moving to beta6+, since it blocks removal of the status bar (bug 574688).

Comment 26

[Tan Wei Lin Jason [:Ryuji]]

PL Need glow or be made taller, or else it is hard for the users to notice PL.

Comment 27

[Tan Wei Lin Jason [:Ryuji]]

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?

Comment 28

[Stephen Horlander [:shorlander]]

(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

Comment 29

[:Margaret Leibovic]

Attachment: WIP

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)

Comment 30

[:Margaret Leibovic]

Attachment: WIP screenshot

Comment 31

[Leonardo Nascimento]

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.

Comment 32

[u88484]

(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.

Comment 33

[:Margaret Leibovic]

Attachment: patch

I'm not sure how this looks on Linux and Windows, but if the styling for bug 544818 works, this should hopefully work.

Comment 34

[Asaf Romano (gone)]

Dao: if you don't have time for this review, you can set the request on me.

Comment 35

[:Margaret Leibovic]

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?

Comment 36

[:Margaret Leibovic]

Attachment: patch v2

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.

Comment 37

[:Margaret Leibovic]

(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.

Comment 38

[Dão Gottwald [:dao]]

You should take a look at bug 587908, there will be conflicts.

Comment 39

[Dão Gottwald [:dao]]

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.

Comment 40

[:Margaret Leibovic]

Attachment: wip for patch v3 (mac theme only)

Comment 41

[:Margaret Leibovic]

Attachment: patch v3

Needs to be tested on linux/windows.

Comment 42

[:Margaret Leibovic]

(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?

Comment 43

[Asaf Romano (gone)]

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.

Comment 44

[Asaf Romano (gone)]

Oh, I missed the new patch...

Comment 45

[Asaf Romano (gone)]

Comment on attachment 475623 [details] [diff] [review]
patch v3

The comments still stand.

Comment 46

[:Margaret Leibovic]

Attachment: patch v4

Fixed id issue.

Comment 47

[:Margaret Leibovic]

(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.

Comment 48

[Asaf Romano (gone)]

1. How do you move the element to browser.xul?
2. I wonder if a stack should be used for this overlapping effect.

Comment 49

[:Margaret Leibovic]

Attachment: patch v5

Cleaned up css.

Comment 50

[Asaf Romano (gone)]

Comment on attachment 475652 [details] [diff] [review]
patch v5

r=mano. The css will need further cleanup, but that's good to go.

Comment 51

[:Margaret Leibovic]

Attachment: patch v6

Fixed progress bar height problem for linux/windows, and fixed history dropmarker padding.

Comment 52

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 53

[:Margaret Leibovic]

Attachment: patch v7

Comment 54

[:Margaret Leibovic]

http://hg.mozilla.org/mozilla-central/rev/22c4d4151710

Comment 55

[Paul [pwd]]

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?

Comment 56

[Benjamin Xiao]

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.

Comment 57

[Peter Henkel [:Terepin]]

Use add-on as before.

Comment 58

[Peter Henkel [:Terepin]]

Margaret, current PL is only placeholder, am I correct?

Comment 59

[José Jeria]

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.

Comment 60

[Csaba Kozák [:WonderCsabo]]

Pie charts will replace by progress lines on all tabs, and will be on the top of the tabs. Check attachment 474291 [details] !

Comment 61

[Benjamin Xiao]

(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.

Comment 62

[u88484]

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!

Comment 63

[[not reading bugmail]]

Is there a reason blue got implemented instead of the green in the mockup (besides it matching the default theme)?

Comment 64

[avada]

(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.

Comment 65

[Dave Garrett]

(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. :)

Comment 66

[Benjamin Xiao]

(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.

Comment 67

[Daniel Spiewak]

(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.

Comment 68

[Asaf Romano (gone)]

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.

Comment 69

[[not reading bugmail]]

(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

Comment 70

[u279076]

Litmus testcase added:
https://litmus.mozilla.org/show_test.cgi?id=12904

Comment 71

[antistress]

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 )

Comment 72

[Dave Garrett]

(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.

Comment 73

[pd]

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!

Comment 74

[Johnathan Nightingale [:johnath]]

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.

Comment 75

[Csaba Kozák [:WonderCsabo]]

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.

Comment 76

[Peter Henkel [:Terepin]]

(In reply to comment #73)
> No stuffing about, just do it!

Will do, just after I put my foot into your face...