Closed Bug 564589 Opened 15 years ago Closed 13 years ago

Request to add ability to auto-hide Bookmarks Toolbar

Categories

(Firefox :: Bookmarks & History, enhancement)

x86
Windows Vista
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: wddn836, Unassigned)

References

Details

(Whiteboard: [parity-chrome])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; zh-TW; rv:1.9.2.4) Gecko/20100503 Firefox/3.6.4 ( .NET CLR 3.5.30729; .NET4.0E) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; zh-TW; rv:1.9.2.4) Gecko/20100503 Firefox/3.6.4 ( .NET CLR 3.5.30729; .NET4.0E) I hope I would be able to auto-hide the Bookmarks Bar when not in use, and show up only if the cursor hover above it for a fixed period of time. I also appreciate if FF auto-hides the scroll bar on the right side and show it only when people scroll up/down with a mouse. This can increase the viewing space for Firefox. Also, it would be nice to show the no. of unreaed feeds, and manually refresh the RSS feeds for the most updated news. Reproducible: Always
For the scroll bar, it can also show up constantly when one doesn't have a mouse scroll or when the webpage is long enough.
Please only one issue per bug. I suggest to focus this bug on making the Bookmarks Toolbar auto-hide (which I think is a great idea). - The Bookmarks Toolbar should auto-unhide whenever the mouse moves anywhere into the UI above the content (e.g., Menu Bar, Navigation Toolbar). - The Bookmarks Toolbar should auto-hide after about 3 seconds either when the user moves the mous into the page content (to continue reading, pointing, scrolling) or if the mouse stops moving for ~3 seconds (even if it in the UI). - The Bookmarks Toolbar should slide out (to draw attention to what happened). This feature would save some vertical space, and make the unfortunate removing of the Bookmarks Toolbar per default in Firefox 4 unnecessary. PS. Please fix the Subject of this bug: change "Bookmarks Bar" to "Bookmarks Toolbar".
BTW: I also just filed bug 577215, which will also make the unfortunate removing of the Bookmarks Toolbar per default in Firefox 4 less necessary. PS. Please fix the Subject by removing the other issues not related to this bug (i.e., "scroll bar and show unread RSS feeds").
Summary: Request to add ability to auto-hide Bookmarks Bar & scroll bar and show unread RSS feeds → Request to add ability to auto-hide Bookmarks Toolbar
I don't think an autohide toolbar is a nice idea. first the toolbar is going to be hidden by default, second this would cause any sort of jumping around for content, and unexpected clicks when trying to use top menus in websites. Personally I'd wontfix a request for such a feature. The toolbar ins intended for a faster access to some bookmarks, if you're going to implement a spring load behavior than you'd take the same time accessing the menu or the new bookmarks button.
Component: General → Bookmarks & History
QA Contact: general → bookmarks
(In reply to comment #4) > the toolbar is going to be hidden by default, It shouldn't be. This bug is trying to avoid that scenario by combining the best from both worlds. > this would cause any sort of jumping around for content The Bookmarks Toolbar would not "jump", it would slide out. And it should be tested whether moving the content down or sliding over the content would be better. Since the Bookmarks Toolbar would appear only temporarily, I think it should slide over the content. > unexpected clicks when trying to use top menus in websites. This is the only issue I don't have a good solution for yet. I think most web pages don't have their menus at the very top. So this is probably not a significant issue. > The toolbar ins intended for a faster access to some bookmarks, if you're going > to implement a spring load behavior than you'd take the same time accessing the > menu or the new bookmarks button. The Bookmarks Toolbar provides a (usually) flat list of favorite (i.e. "frecent") bookmarks - whereas the Bookmarks Menu is loaded with many more bookmarks (mine's loaded with folders and sub-folders). I still think an auto-hiding Bookmarks Toolbar will be faster, easier, and more discoverable.
(In reply to comment #5) > unexpected clicks when trying to use top menus in websites. Maybe we can slide out the Booksmark Toolbar only when the mouse moves into the upper part of the UI (e.g. Tabs bar in Firefox 4) to avoid it from showing up accidentally. We may also consider adding a button for faster hiding in case the user wants to use the tops menus of a website after using the Booksmarks Toolbar.
FYI I've just filed bug 577629 which hopefully can improve the experience of RSS feed users.
(In reply to comment #6) > (In reply to comment #5) > > > unexpected clicks when trying to use top menus in websites. > > Maybe we can slide out the Booksmark Toolbar only when the mouse moves into the > upper part of the UI (e.g. Tabs bar in Firefox 4) to avoid it from showing up > accidentally. Or maybe NOT unhide the Bookmarks Toolbar within the first few pixels of the UI. However, this (invisible line) might be confusing or seemingly inconsistent for users. And it would be annoying for those who want to quickly trigger the Bookmarks Toolbar. I still think menus at the very top is such a rare case that for those very rare cases users will quickly understand that they just need to aim a bit more carefully so as to not move into the UI. And users typically "approach" the menu from the bottom (the cursor typically is within the content while reading), so they will likely click the page's menu item before they "overshoot" into the UI.
I know menu on top is a rare case but still I think it's better to solve it in the long term, as Firefox should provide a great experience on all web pages. I think another solution will be to do something like the Microsoft Kinect. Move the mouse into the UI, a small circle is drawn clockwise in a corner, and when the the circle is completely drawn (takes about a sec or two), the circle disappears and a semi-transparent (maybe with 70-80% obesity) Bookmarks Toolbar slides out. If the user finds it annoying, they shd be able to turn this off. Let them choose to show the Toolbar permanently, show up like I said before, or simply disable it. Apparently Peter's solution and mine both have their pros and cons (Mine seems to be a bit more annoying and CPU intensive, but solves the "invisible line" issue). It's just an alternative anyway. I really hope the developers can think about implementing it. :)
Auto-hiding/showing the bookmarks toolbar seems to busy for me. I like it for the quick access it provides to certain (favorite) pages, that's why I have it enabled in FF4. But it uses up space which I only need a fraction of the time I uses FF. My suggestion is to have it show together with the menu when you hit the Alt-button.
But won't it be a bit too complicated for a normal user to open up a Bookmarks Toolbar?
Maybe. But during regular use of FF it would be bothering (me) if the Bookmarks Toolbar would appear every time the mouse is moved in a certain area. For the few times it is actually used, this seems like accessive behaviour. Another possibility would be for the toolbar to appear when the Bookmarks button is pressed. Although the popup menu might partially obscure the toolbar...
The current trend is to avoid "magic" behaviors in the toolbars as far as possible, since those always end up creating more bugs and unexpected behaviors than expected, plus complicating the code. So this is not something we are interested into supporting as a core feature.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Chrome has nice solution for this - the bookmarks toolbar is shown on the New Tab page, but not when a web page is open. Marko, is this still not something we might consider?
Flags: needinfo?(mak77)
Whiteboard: [parity-chrome]
I don't know, that's a question for UX. Off-hand I think it's still a legacy solution. Having a better new tab page should in general be better than hiding/showing a toolbar.
Flags: needinfo?(mak77)
Duplicate of this bug: 1981486
You need to log in before you can comment on or make changes to this bug.