Allow bookmarks button in the nav bar even when bookmarks bar is showing

RESOLVED DUPLICATE of bug 581238

Status

()

RESOLVED DUPLICATE of bug 581238
8 years ago
6 years ago

People

(Reporter: atzaus, Unassigned)

Tracking

unspecified
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox7-)

Details

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b3pre) Gecko/20100725 Firefox/4.0b3pre
Build Identifier: 

When the bookmarks bar is showing all you can have is the Bookmarks Folder/Menu which you cannot drag to the nav bar. This IMO is a waste of space on the bookmarks bar and for people like me who have it filled out without overflowing it is a major inconvenience. In comparison all the nav bar has is B/F button URL and Search bar so allowing the user to move it there would help them save space.

Reproducible: Always
(Reporter)

Updated

8 years ago
Blocks: 544817
(Reporter)

Comment 1

8 years ago
For reference
<wx24> is there no way to move the bookmarks button to the navbar while the bookmarks bar is showing?
<dholbert> wx24, mm, that seems broken in my build
<dholbert> wx24, when I right-click one of the bars & pick 'customize', the bookmarks button snaps up next to the navbar. But when I finish customizing, it snaps back to bookmarks toolbar
<wx24> I seriously don't get why you want to move it to the bookmarks toolbar when it is showing...instead of wasting space there I woul rather have another folder which is now out of view
<dholbert> wx24, I don't think it's intentional -- looks like a bug, I'd say.  mind filing?
navbar will also have (And has) a bunch of other icons and add-ons icons, and that's why the bookmarks button moves to the bookmarks if they are visible, to save space in the navbar.
(Reporter)

Comment 3

8 years ago
(In reply to comment #2)
> navbar will also have (And has) a bunch of other icons and add-ons icons, and
> that's why the bookmarks button moves to the bookmarks if they are visible, to
> save space in the navbar.

When it moves the user should at least be given a choice to drag it back...for users who don't have that many addons but want to use all of the bookmarks bar

Updated

8 years ago
Duplicate of this bug: 595880

Updated

8 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

8 years ago
(In reply to comment #2)
> navbar will also have (And has) a bunch of other icons and add-ons icons, and
> that's why the bookmarks button moves to the bookmarks if they are visible, to
> save space in the navbar.

Especially now that the Addons Bar is coming, it will be even less likely for the navbar to have a bunch of add-on icons. Would it be possible to at least provide the option for someone to manually move the button where they want it? Given the constant insistence through most Firefox 4 design decisions of having everything be movable, this seems oddly against the grain to force the position of this single button. This is also reduced behavior from Firefox 3.6. There, you had a completely blank bookmark bar that you could place links on. Granted, it seems you could still achieve that here by turning on the Menu Bar and using the Bookmarks item under there instead (which would mimic Firefox 3.6 exactly), and removing the Bookmarks button altogether through customize. But then, that has the added Menu Bar for that single item, completely undoing any space savings. By allowing the user to drag the Bookmarks button to the Nav Bar, no Menu Bar is necessary, and you again get the full width of the Bookmarks bar for links.

Comment 6

8 years ago
I support this bug report.

I put the bookmarks item list into the tab toolbar to save vertical space. But the bookmarks button should stay in the navbar, because the space in the tab toolbar is limited.

Comment 7

8 years ago
The current behavior is a pain in the a**.
Only sometimes i have the bookmark toolbar, and having the bookmark button 'hop' between 2 locations is not very good.  
Also, if i did want it on the bookmarks toolbar, why the hell would i want it stuck all the way over to the right, when the rest of the bookmarks align to the left of the toolbar?.

Updated

8 years ago
Duplicate of this bug: 593693
so what currently happens is this:
1. if menubar is visible no button is visible (if it is visible in the customization palette, that's a bug to fix)
2. if bookmarks toolbar items are visible (ANYWHERE) the button attaches to them.
   this is by design but causes the following issues:
     a. when customization starts the button detaches from bookmarks and comes
        back to the original position, this happens because bookmarks items are
        hidden, so it can't stay there.
     b. some user wants the button to be visible in a certain position regardless
        the fact bookmarks toolbar items are visible or not. This is tricky
        because we have that magic attach/detach code. If we stop doing magic
        when the user customizes the button, then there will be no way to
        reactivate it.

The simplest solution would be to make the button a non magic button, where the user just puts it in a position and it stays there, without attach/detach to bookmarks. The complex solution is to try to solve a. and b. without losing the attach-to-bookmarks behavior.
(In reply to comment #7)
> Also, if i did want it on the bookmarks toolbar, why the hell would i want it
> stuck all the way over to the right, when the rest of the bookmarks align to
> the left of the toolbar?.

As a side note, you can move it to the left of the bookmarks toolbar, and it will stick there.

Comment 11

8 years ago
AAhh...i should have been a little more forthcoming in my post instead of a mild rant.. 
For example, if the bookmark button resides in the urlbar, and i open the bookmark toolbar, its response is to hop to the bookmark toolbar.
But, this action would be more acceptable if the bookmark button would align itself to the hard left, before the bookmark toolbar items, instead of the extreme right, where its a long mouse travel to click it open.
Any chances to get this fixed with final Firefox 4 ? ;)
Also how about nominating it for blocker

Comment 13

8 years ago
Might this be directly related to:
https://bugzilla.mozilla.org/show_bug.cgi?id=581238
They seem near opposite, but both indicate a config setting failure.

Updated

8 years ago
Duplicate of this bug: 644141

Comment 15

8 years ago
I'd personnaly be more than happy if this button is transformed into a normal, non-magic one. It seems against firefox spirit to force customization in such a rigid way (I do realize that the feature may be great for other users, no offense).

I did put the button in the left of the bookmark bar as I have figured this out by myself but what I would like to get is this button in the nav bar while bookmark bar is showing. This is impossible and it really feels like a bug.
What's the status on this ? Will it make it in Firefox 5?
Asking, because 12th deadline is approaching fast ;p
Any chance this can make into Firefox 6?
Branching is in a week.
please don't ping for bugs.

Comment 20

7 years ago
Virtual_ManPL, I've said it in other bugs but I'll repeat it here. Your participation so far in Bugzilla is not appropriate and definitely not helpful. If you'd like to discuss this with me, I can be reached at asa@mozilla.org. In the mean time, I'm asking you to stop setting bug flags or commenting. Thanks.
tracking-firefox7: ? → -

Comment 21

7 years ago
This "move to bookmarks toolbar and show text" is very annoying.
When a user customises the position of their buttons they should stay put and not override users' wishes.
I suggest having a normal bookmarks menu button too that stays put - without any of the weird moving and hiding features.
yep, especially when you select only SHOW ICONS, not show icons with text...

Updated

7 years ago
Duplicate of this bug: 740250

Updated

7 years ago
Depends on: 748894

Updated

6 years ago
Whiteboard: [DUPEME?/blocks 581238]

Comment 24

6 years ago
I second for removing the dynamic behaviour of the Bookmarks Button altogether, making it a normal customisable items, just like all other items. I challenge the original rationale behind this *magic button feature*:

(1) Users who normally enable Bookmarks Toolbar can manually disable Bookmarks Button via Customisation UI.  Vice versa, those who normally disable Bookmarks Toolbar can enable the Button.  This *magic feature* only facilitate someone who may want to enable and disable the Bookmarks Toolbar from time to time. I believe those users are in the minority.

(2) As for Menu Toolbar, many items are in both the customisable UI and Menu Toolbar.  When the Menu Toolbar is visible, none of them hide magically like the Bookmarks Button do and they works perfectly fine.  So the feature is not needed to begin with.

(3) With the recent Ubuntu FF modifications addon, Menu Toolbar is merged with the system toolbar and is considered ALWAYS active.  As a result, there is absolutely no method to show the Bookmarks Button at all.  Although technically this is a bug of the modification extension, but the addon is included in Ubuntu distro by default.  It's indistinguishable from a core bug unless one really really look into it.

(4) As mentioned above, users who may benefit from this *magic button feature* are in the minority. These kind of features should be moved out of the core into optional addons.  Unnecessary features are not only bad for performance and usability, they also add complications - making codes more difficult to maintain and encourages bugs to arise.  The Ubuntu bug is a good example. 


So, please please please remove this bloatware-like feature, completely.  I like FF and Mozilla project in general but these bloatware features are annoying.
just duping since we don't plan to further do magic here.
bug 748894 will just make this pointless.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Whiteboard: [DUPEME?/blocks 581238]
Duplicate of bug: 581238

Comment 26

6 years ago
(In reply to Mathieu from comment #16)
> https://addons.mozilla.org/fr/firefox/addon/bug582139/

The comment doesn't mention that this link is an add-on that fixes the dodgy behaviour.
You need to log in before you can comment on or make changes to this bug.