Closed Bug 598938 Opened 14 years ago Closed 14 years ago

Add-on bar wastes horizontal screen real state

Categories

(Firefox :: Toolbars and Customization, defect)

Product:
Firefox
Component:
Toolbars and Customization
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
Firefox 4.0b7

People

(Reporter: alex_mayorga, Unassigned)

References

(
URL
)

Details

Attachments

(2 files)

Wasted horizontal screen real state.
28.76 KB, image/jpeg
Details
Solution of the problem we run into when we place the addonbar over the page content. Left: at the bottom of the page. Right: Scroll beyond it.
11.87 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows NT 6.0; rv:2.0b7pre) Gecko/20100923 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (Windows NT 6.0; rv:2.0b7pre) Gecko/20100923 Firefox/4.0b7pre

It should adjust "automagically" to the space needed by add-ons.

Reproducible: Always

Steps to Reproduce:
1. Click "View" > "Toolbars" > "Add-on Bar" with at least an add-on that shows an icon.
Actual Results:  
The add-on bar wastes horizontal screen real state.

Expected Results:  
It should adjust "automagically" to the space needed by add-ons.

Blocks bug 574688?
Blocks: 574688

    
    

    
  
This was one of the ideas for addons bar, but it was dropped. 
http://jboriss.files.wordpress.com/2010/06/third_growing_statubar.png

It would be ugly with more addons. (or with Forecastfox only...)

    
    

    
  
Not to mention that that AddOn Bar currently cuts off vertical space from the content frame. The issue with the "only as big as it needs to be" hovering bar was also that it would block frequent content controls in the bottom right hand corner that sites (namely - Facebook) use. If it were automatically resizing and still cutting off the vertical space, that would look ridiculous. A full size bar is really the only goo current compromise.

    
    

    
  
This discussion has been had to death. Can we mark this RESOLVED WONTFIX or INVALID

    
    

    
  
Make the entire bar transparent, giving an illusion of more space for content.

    
    

    
  
Bad idea. It would look very ugly with addon icons and under web content. And would make addon icons harder to read.

    
    

    
  
(In reply to comment #5)
> Make the entire bar transparent, giving an illusion of more space for content.

That would be bug 597949. While I agree that the toolbar doesn't look too visually appealing right now. Making it the colour of the upper toolbars or better yet the background tabs would be an improvement for me. Either way, not a discussion for this bug.

    
    

    
  
Now I have an idea, how about we put the complete URL of hovered links on that wasted space... wait! =D

    
    

    
  
(In reply to comment #8)
> Now I have an idea, how about we put the complete URL of hovered links on that
> wasted space... wait! =D

Agree.

Is there a bug about that? If not let's open one.

    
    

    
  
(In reply to comment #9)
> Agree.
> 
> Is there a bug about that? If not let's open one.

That was a joke. That's not happening "officially" so I wouldn't bother with a bug. Now that the AddOn bar is in, I would expect an addon fairly soon to restore the functionality. There's already talk about it over in the main AddOn Bar bug.

    
    

    
  
I got to thinking, how about displaying the Find bar within the Addon Bar?

    
    

    
  
I don't care about the length of the bar, but as it is now, it's too high, needs to be cut by at least 3 or 4 pixels.

    
    

    
  
(In reply to comment #12)
> I don't care about the length of the bar, but as it is now, it's too high,
> needs to be cut by at least 3 or 4 pixels.

That is bug 598921

    
    

    
  
I prefer growing bar mentioned in comment#2.

But problem of the growing bar is that there exists inaccessible
content under the bar.

.........................................................|
.................... Inaccessible content   *------------|
Bottom of contents.. under the Add-on Bar ->| Add-on Bar |
---------------------------------------------------------*

Here is the solution of the problem:
contents area can be scrolled up to the top of the bar.

........................................................ |
Bottom of contents...................................... |
                                            *------------|
                                            | Add-on Bar |
---------------------------------------------------------*

    
    

    
  
Boriss, your final post (3 of 2) on the add-on bar does talk about this, but we talked afterwards and decided on a full-width bar. What are your current thoughts on doing this?

http://jboriss.wordpress.com/2010/06/16/removing-firefox%E2%80%99s-status-bar-and-rehousing-add-on-icons-part-3-of-2-wut/
Component: General → Toolbars
OS: Windows Vista → All
QA Contact: general → toolbars
Hardware: x86 → All

    
    

    
  
(In reply to comment #15)
> Boriss, your final post (3 of 2) on the add-on bar does talk about this, but we
> talked afterwards and decided on a full-width bar. What are your current
> thoughts on doing this?
> 
> http://jboriss.wordpress.com/2010/06/16/removing-firefox%E2%80%99s-status-bar-and-rehousing-add-on-icons-part-3-of-2-wut/

Can't find the comment, but I do recall that Boriss recently reiterated that a semi-bar in the view-port causes usability problems. I do however think that having a semi-bar outside of the view port wouldn't be such a bad idea is we made the unused space glass for Vista/Windows 7.

    
    

    
  
(In reply to comment #14)
> Here is the solution of the problem:
> contents area can be scrolled up to the top of the bar.

There is an extension which already does this:
Yet another Smooth Scrolling (https://addons.mozilla.org/en-US/firefox/addon/5846/)

    
    

    
  
Well, I understand the problems with only-as-big-as-it-needs-to-be addon bar, but could anyone, please, tell me now what we substituted progress-circle-in-the-favicon and link-URL-in-the-address-bar for status bar for? What is the reason for this now when we have yet another bar there in the bottom again? Now, the addon bar is just a status bar which is not showing “status”.

    
    

    
  
(In reply to comment #18)
> Well, I understand the problems with only-as-big-as-it-needs-to-be addon bar,
> but could anyone, please, tell me now what we substituted
> progress-circle-in-the-favicon and link-URL-in-the-address-bar for status bar
> for? What is the reason for this now when we have yet another bar there in the
> bottom again? Now, the addon bar is just a status bar which is not showing
> “status”.

Most normal users won't have any bar visible, so removing the status bar by default is a win for them. There are already add-ons for showing the old status information in the add-on bar.

    
    

    
  
Marking this WONTFIX. There are add-ons to do this, and Boriss already discussed in her blog why we didn't want to do this by default in the product.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX

    
    

    
  
is there a possibility to achieve something like this?
http://jboriss.files.wordpress.com/2010/06/third_growing_statubar.png

if yes, then please specify which one(s) do that instead of just claiming there would be some ;)

    
    

    
  
> Marking this WONTFIX. There are add-ons to do this, and Boriss already
> discussed in her blog why we didn't want to do this by default in the product.

where did Boriss say we don't need that anymore?
or it was actually marked as WONTFIX because mozdev team just can't handle so much (changing release date for a few months more just proves that version).

    
    

    
  
(In reply to comment #21)
> is there a possibility to achieve something like this?
> http://jboriss.files.wordpress.com/2010/06/third_growing_statubar.png
> 
> if yes, then please specify which one(s) do that instead of just claiming there
> would be some ;)

Oops, sorry let me look it up, will post back here.

(In reply to comment #22)
> or it was actually marked as WONTFIX because mozdev team just can't handle so
> much (changing release date for a few months more just proves that version).

This is Mozilla. *You* are part of the team. If you're willing to post a patch, or at least some ideas, instead of negative comments, I'm glad to take a look :)

    
    

    
  
Boriss, did you post on why you moved away from the partial-width approach? I can't find it. Otherwise, can you comment here on why? I've got some idea, but I don't want to sully your vision ;)

    
    

    
  
(In reply to comment #25)
> Boriss, did you post on why you moved away from the partial-width approach? I
> can't find it. Otherwise, can you comment here on why? I've got some idea, but
> I don't want to sully your vision ;)

I remember reading it. I think it may have been in the newsgroup discussion. I distinctly remember reading the comment.

    
    

    
  
(In reply to comment #23)
> This is Mozilla. *You* are part of the team. If you're willing to post a patch,
> or at least some ideas, instead of negative comments, I'm glad to take a look
> :)

The bug is not "NEW", it's "RESOLVED WONTFIX" meaning that if there was a patch - anyways it won't be applied.
And my idea - is the old one - make the addon's bar width be a sum of it's children-elements' widths.
Your idea to block that bug - means to waste much space on the screen. Why? My negative comment was just caused by a bad idea of wasting screen space.
Even if you find the Boriss comment, will it change anything? The bad idea remains bad, until there is a really serious reason not to implement the dynamic width. That's why I wonder what the reason is.

    
    

    
  
(In reply to comment #23)
> If you're willing to post a patch,

All I know is CSS, so I used a style to make the Add-on Bar have dynamic width:

All the adjustments in that style are tested to work good on Win 7 and (other users told me so) on XP too. I think Linux/MacOS variant may differ a little, depending of their theme.

/* Add-on Bar and Findbar */
/* As findbar is a part of browser-bottombox, it is also affected and this style has some fixed for the findbar to look pleasant.
#browser-bottombox {
   position: fixed;
   bottom: 0px;
   right: 17px;  /* This is actually wrong, but it is written for add-on bar not to get overflown by page's scrollbar. And it has a bug: if there's no scrollbar on the page - the add-on bar still will be 17px away from right edge of the window. This actually can be fixed quite easily by moving add-on bar element as a child to the page scrollbar's parent, so they would be "brothers", I just can't do it using only CSS and don't want to manually brake DOM structure of elements, as I would need to do it every day for a newer nightly build. */
   width: auto;
   border: 0 !important;
   background: none !important;}
#addon-bar, #FindToolbar {
   -moz-appearance: none !important;
   -moz-border-radius: 6px 6px 0 0;
   border: 1px solid black !important;
   border-bottom: 0 !important;
   background-color: -moz-dialog !important; }
#FindToolbar { 
   position: fixed; /* I've found that having findbar at left bottom of the window is a better idea, than having it just at left or above the add-on bar */
   left: 0; }
#addon-bar, #FindToolbar, #linkTargetDisplay {
   background: -moz-linear-gradient(-90deg,rgba(255,255,255,.5),rgba(1,1,1,.5)) !important;
   text-shadow: 0 0 1em white, 0 0 1em white;
   -moz-box-shadow: 0 0 9px rgba(0,0,0,.4) inset, 0 0 3px rgba(0,0,0,.4) inset, 0 1px 0 rgba(255,255,255,.4)!important;
   color: black !important; }
#status-bar {
   background: none !important; }

If you would add a button to the bottom glass border of Firefox's window, and if clicking it would toggle showing/hiding add-on bar - I think I could use transitions effect to make add-on bar slowly appear-disappear behind bottom edge.

    
    

    
  
oh, and I wish background: -moz-win-glass; would work for find-bar and addon-bar, but for some (unknown for me) reason - it doesn't. And I didn't find a corresponding bug about it here, in Bugzilla. Should I create one?

    
    

    
  
(In reply to comment #21 comment #25 and comment #26)

I believe the partial width bar would have ended up drawing over the top of webpage elements that are locked to the bottom of the browser window, e.g. Facebook Chat. I can't find the newsgroup discussion either.

    
    

    
  
(In reply to comment #26)
> (In reply to comment #25)
> > Boriss, did you post on why you moved away from the partial-width approach? I
> > can't find it. Otherwise, can you comment here on why? I've got some idea, but
> > I don't want to sully your vision ;)
> 
> I remember reading it. I think it may have been in the newsgroup discussion. I
> distinctly remember reading the comment.

Are you referring to this message?
http://markmail.org/message/vb4r2wul62l3mwch

If that's the message you were mentioning, I can't see any reasons given apart from a description of the plan:
"The plan for the add-on bar is that it will span the entire width of the page. It would be summoned and dismissed via a small button, similar to this (imagine the add-ons bar spans the entire page)."


This one seems a reason, though:
https://jboriss.wordpress.com/2010/06/16/removing-firefox%E2%80%99s-status-bar-and-rehousing-add-on-icons-part-3-of-2-wut/#comment-1951

And comment 14 is a proposed solution for that.

    
    

    
  
(In reply to comment #31)
> This one seems a reason, though:
> https://jboriss.wordpress.com/2010/06/16/removing-firefox%E2%80%99s-status-bar-and-rehousing-add-on-icons-part-3-of-2-wut/#comment-1951
> 
> And comment 14 is a proposed solution for that.

But how is that solution any different from just having an add-on bar that spans the entire page width? If you're moving up all the content above that add-on bar anyhow, won't that make it so that the space to the left of the smaller add-on bar, all the way to the other side of the browser, is blank anyway? I guess I'm missing how that's "better". Surely it's just semantics at that point vs the way it is now.

    
    

    
  
i think we all know that, but in his blogpost “part 3 of 2”, boriss addressed this by making it hideable.

and comment 14 offered a even greater solution: the possibility to scroll beyond the page content. i would specify this as follows:

when you arrive the bottom of a page, the scrolling stops. if you wait a split second, you can scroll beyond the page content, just as far as the addon bar is high, so you can access every single pixel of the page. this looks kind of like on the iphone (the page has a shadow and the browser-ui-colored/glass background appears below it). you can then access the elements there. if you don’t focus any of them, the page slowly scrolls back after a second or so. if the page doesn’t have a vertical scrollbar, it doesn’t get one when scrolling beyond the page, but when it has one, the bar shrinks a bit according to added page height.

while this change is surely not trivial to implement, it would offer the functionality we all are looking for in a totally intuitive way.

    
    

    
  
(In reply to comment #30)
> I believe the partial width bar would have ended up drawing over the top of
> webpage elements that are locked to the bottom of the browser window, e.g.
> Facebook Chat.

That's why that bar should get auto-hidden if not active (for x sec, maybe). And if the user needs it - he may click on the button and the addon bar should appear.

    
    

    
  
(In reply to comment #33)
> and comment 14 offered a even greater solution: the possibility to scroll
> beyond the page content. i would specify this as follows:
> 
> when you arrive the bottom of a page, the scrolling stops. if you wait a split
> second, you can scroll beyond the page content, just as far as the addon bar is
> high, so you can access every single pixel of the page.

I don't think it's a good idea, as pages can be very loooong, and user would have to scroll till the end, to see the addon-bar.

    
    

    
  
(In reply to comment #30)
> I believe the partial width bar would have ended up drawing over the top of
> webpage elements that are locked to the bottom of the browser window, e.g.
> Facebook Chat.

+ I also stumbled upon that problem with my suggested CSS style, that's why I actually added opacity to findbar and add-on bar, until they are hovered.

    
    

    
  
This is awesome. Thanks for posting your CSS, Mr. 1luvm0z1l4.

It would be cool if this was converted to an extension, so people could easily test it out. I'll try it out for sure.

(In reply to comment #29)
> oh, and I wish background: -moz-win-glass; would work for find-bar and
> addon-bar, but for some (unknown for me) reason - it doesn't. And I didn't find
> a corresponding bug about it here, in Bugzilla. Should I create one?

Yep, file a new bug, thanks!

    
    

    
  


  
(In reply to comment #35)
> (In reply to comment #33)
> I don't think it's a good idea, as pages can be very loooong, and user would
> have to scroll till the end, to see the addon-bar.
please read comment 14 and/or comment 33 again, you completely misconceived what we said. or check my mockup if you don’t like reading.

    
    

    
  
(In reply to comment #38)
> Created attachment 486949 [details]
> Solution of the problem we run into when we place the addonbar over the page
> content. Left: at the bottom of the page. Right: Scroll beyond it.

oh, I got your idea wrong at first. Now I get it. But actually in case you scroll lower than page's bottom - the space at left from add-on bar will be unused, which is equal to have it as wide as window is.
but it's still better than how it currently is, when it is wide even when you are not at the bottom of the page.

(In reply to comment #37)
> This is awesome. Thanks for posting your CSS, Mr. 1luvm0z1l4.

Dietrich, don't you remember me? It's my 4th or 5th account already, as previous ones were banned :)

> It would be cool if this was converted to an extension, so people could easily
> test it out. I'll try it out for sure.

It can be installed with stylish, or copied to userChrome.css file in profile folder, or... here is the add-on: http://db.tt/X6gqZFl
 
> (In reply to comment #29)
> Yep, file a new bug, thanks!

Could you please try it on your machine? Don't want to create another bug that will immediately marked as RESOLVED INVALID (or WORKSFORME) in a minute.

    
    

    
  
(In reply to comment #39)
> Dietrich, don't you remember me? It's my 4th or 5th account already, as
> previous ones were banned :)

really?! well, i guess the next question is: what have you learned from being banned so many times? ;)

> > It would be cool if this was converted to an extension, so people could easily
> > test it out. I'll try it out for sure.
> 
> It can be installed with stylish, or copied to userChrome.css file in profile
> folder, or... here is the add-on: http://db.tt/X6gqZFl

THANKS! I've been running with the userChrome.css changes for a couple of days. It obviously needs work to fit in with the theme, but a few other notes:

* the transparency is more distracting than helpful IMO

* because content is partially covered, i'm not sure this approach is better than just having the bar autohide or something like that. eg: having half of a sentence be visible doesn't help me at all.

I'd like to see Boriss weigh in on it, and other people's input who try these changes.

> > (In reply to comment #29)
> > Yep, file a new bug, thanks!
> 
> Could you please try it on your machine? Don't want to create another bug that
> will immediately marked as RESOLVED INVALID (or WORKSFORME) in a minute.

One of the costs of being an awesome contributor like yourself is that you get bugs closed sometimes. C'est la vie.
Target Milestone: --- → Firefox 4.0b7

    
    

    
  
(In reply to comment #40)
> * the transparency is more distracting than helpful IMO
> 
> * because content is partially covered, i'm not sure this approach is better
> than just having the bar autohide or something like that. eg: having half of a
> sentence be visible doesn't help me at all.

That's why I made it half-transparent so you could read what is written on the page underneath that bar, as I couldn't make it autohide with CSS.

> really?! well, i guess the next question is: what have you learned from being
> banned so many times? ;)

1. That none of the devs care about ppl's opinion, just like beltznebooth, who is in charge of them.
2. That voting system here - is not working, though it can't be removed, as it a part of the game you all play (try to smell good, when you actually taste like sh!t), of making an illusion of something really positive.
3. Many bug backouts prove, that you have a bad manager (hello belzebooth, again), as it was just a large waste of human resources, when at first the things like tab progress bar are done, then they backed out into throbbers; when status elements and link address get removed from status-bar, as it was going to transform into add-on bar, but then suddenly it appears that the bar will just stay looong and empty, as the idea of making narrow (hiding/appearing by click on the button, as it was in design concept) has gone. So the idea with add-on bar failed. Now it's just an old status bar with 1 major improvement - it is now customizable.
4. No one here stands the criticism, that's why it's way easier to give a criticizer a ban, saying "you don't obey the rules", (while mozdevs don't obey them too, but who cares, right?).
5. There are enough of available proxies in the internet, to get new accounts, if I get IP ban.
p.s.: I foresee a new ban :D

> One of the costs of being an awesome contributor like yourself is that you get
> bugs closed sometimes. C'est la vie.

No, it's one of the costs of totalitarianism. This regime works only with a good manager in charge of the process, which mozilla lacks.
As what concerns creating the bug - I did, and it appeared that -moz-win-glass can only be applied to <window> element + you can make some element have glass background, but you'll have to apply the glass for it's parental elements (all of them until <window>) which won't work in the style I suggested.
And I asked why not make an SVG that uses Gaussian Blur (to do the effect of windows glass effect) to be built-in as a background for the elements (other than <window>), if they have -moz-win-glass applied.
And no one answered that (strange, huh?).
+ there's a bug, that SVG can't be applied via CSS, and I don't know how to apply it the other way, so if someone is willing to help me - we could make a glass background for addon-bar and find-bar in my add-on, and that glass would work on other OSes too.

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: