The default bug view has changed. See this FAQ.

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

VERIFIED FIXED

Status

()

Firefox
Location Bar
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: Terepin, Assigned: Margaret)

Tracking

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

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus +

Firefox Tracking Flags

(blocking2.0 beta7+)

Details

Attachments

(3 attachments, 8 obsolete attachments)

(Reporter)

Description

7 years ago
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
(Reporter)

Updated

7 years ago
Blocks: 578025
blocking2.0: --- → ?
Depends on: 544818
OS: Windows 7 → All
Hardware: x86 → All
Version: unspecified → Trunk
(Reporter)

Updated

7 years ago
No longer blocks: 578025
(Reporter)

Updated

7 years ago
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?
(Reporter)

Comment 3

7 years ago
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?
(Reporter)

Comment 5

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

Comment 6

7 years ago
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.
(Reporter)

Comment 7

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

Comment 8

7 years ago
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.
(Reporter)

Comment 9

7 years ago
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

7 years ago
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

7 years ago
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
Blocks: 579521
(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.
(Reporter)

Comment 15

7 years ago
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.
(Reporter)

Comment 17

7 years ago
Different color is covered in different bug.

Comment 18

7 years ago
(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

Comment 22

7 years ago
(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+
Created attachment 470022 [details]
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
(Reporter)

Comment 24

7 years ago
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
(Assignee)

Comment 29

7 years ago
Created attachment 474290 [details] [diff] [review]
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)
Assignee: adw → margaret.leibovic
Status: NEW → ASSIGNED
(Assignee)

Comment 30

7 years ago
Created attachment 474291 [details]
WIP screenshot

Updated

7 years ago
Flags: in-litmus?
(Reporter)

Updated

7 years ago
Depends on: 544818

Comment 31

7 years ago
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

7 years ago
(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.
(Assignee)

Comment 33

7 years ago
Created attachment 474885 [details] [diff] [review]
patch

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

Comment 35

7 years ago
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?
(Assignee)

Comment 36

7 years ago
Created attachment 475206 [details] [diff] [review]
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.
Attachment #474885 - Attachment is obsolete: true
Attachment #475206 - Flags: review?(mano)
Attachment #474885 - Flags: review?(dao)
(Assignee)

Updated

7 years ago
No longer depends on: 544818
(Assignee)

Updated

7 years ago
Attachment #475206 - Attachment is patch: true
Attachment #475206 - Attachment mime type: application/octet-stream → text/plain
(Assignee)

Comment 37

7 years ago
(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+
(Assignee)

Comment 40

7 years ago
Created attachment 475620 [details] [diff] [review]
wip for patch v3 (mac theme only)
(Assignee)

Comment 41

7 years ago
Created attachment 475623 [details] [diff] [review]
patch v3

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)
(Assignee)

Comment 42

7 years ago
(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+
(Assignee)

Comment 46

7 years ago
Created attachment 475638 [details] [diff] [review]
patch v4

Fixed id issue.
Attachment #475623 - Attachment is obsolete: true
Attachment #475638 - Flags: ui-review?(shorlander)
(Assignee)

Updated

7 years ago
Attachment #475638 - Flags: review?(mano)
(Assignee)

Comment 47

7 years ago
(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.
(Assignee)

Comment 49

7 years ago
Created attachment 475652 [details] [diff] [review]
patch v5

Cleaned up css.
Attachment #475638 - Attachment is obsolete: true
Attachment #475638 - Flags: ui-review?(shorlander)
Attachment #475638 - Flags: review?(mano)
(Assignee)

Updated

7 years ago
Attachment #475652 - Flags: review?(dolske)
(Assignee)

Updated

7 years ago
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+
(Assignee)

Comment 51

7 years ago
Created attachment 475704 [details] [diff] [review]
patch v6

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+
(Assignee)

Updated

7 years ago
Blocks: 596812
(Assignee)

Comment 53

7 years ago
Created attachment 475713 [details] [diff] [review]
patch v7
Attachment #475704 - Attachment is obsolete: true
(Assignee)

Comment 54

7 years ago
http://hg.mozilla.org/mozilla-central/rev/22c4d4151710
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Depends on: 596867
Depends on: 596868

Comment 55

7 years ago
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

7 years ago
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.
(Reporter)

Comment 57

7 years ago
Use add-on as before.
(Reporter)

Comment 58

7 years ago
Margaret, current PL is only placeholder, am I correct?

Comment 59

7 years ago
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] !

Comment 61

7 years ago
(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

7 years ago
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)?

Updated

7 years ago
Depends on: 597277
(Assignee)

Updated

7 years ago
Blocks: 597307

Comment 64

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

Updated

7 years ago
No longer blocks: 597307
Depends on: 597307

Comment 65

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

Updated

7 years ago
Depends on: 597421

Updated

7 years ago
Component: General → Location Bar
QA Contact: general → location.bar

Comment 66

7 years ago
(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

7 years ago
(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
Blocks: 597681

Updated

7 years ago
Depends on: 597971
(Assignee)

Updated

7 years ago
No longer depends on: 596868
Litmus testcase added:
https://litmus.mozilla.org/show_test.cgi?id=12904
Flags: in-litmus? → in-litmus+

Comment 71

7 years ago
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

7 years ago
(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

7 years ago
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.
(Reporter)

Comment 76

7 years ago
(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

Updated

7 years ago
Depends on: 605409
You need to log in before you can comment on or make changes to this bug.