447571 - bookmarks expansion broken when all items are put on a single toolbar

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect, P3)

Description

[Stephen Walker]

[menu][bookmarkstoolbar][unifiedbackforward][stop][reload][urlbar][searchbar]
is now shown as 
[menu][overflow
expander(>>)][unifiedbackforward][stop][reload][urlbar][searchbar]

Opening the customize toolbar dialog window is a workaround for now since
closing the dialog window forces the bookmarks toolbar to expand.

Comment 1

[Mathieu Johnson]

This bug has been aggravated since the date it was filed (on Windows at least). Now the problem comes back each time the window is minimized then restored. The workaround must be applied after each window minimization/restoration cycle now. 

Comment 3

[Brian Polidoro]

You can also see the problem during resize and even in 3.0.  What I see is while narrowing the browser window when the a/s bar (address or search) reaches it's minimum width then the bookmark toolbar starts to collapse.  That's ok.  That's even better than 2.0 which would result in the bookmark toolbar not collapsing and the a/s bar going out of view.  

But the problem is shown when widening the window.  The a/s bar widens but never allows the bookmark toolbar to get its space back so it can uncollapse.  

So bug 443734 just exposed the existing problem at startup. 

Also a possibly better workaround is to right click on the chevron and use Sort By Name to get the bookmark toolbar to expand.

Comment 4

[Alice0775 White]

Attachment: patch for places\toolbar.xml

I am not familiar with Source tree, therefore the patch is for the nightly windows build.

Comment 5

[Ken Takusagawa]

I suspect this bug is a duplicate of bug 427280.

Comment 7

[Ken Takusagawa]

This patch works for me.

Comment 8

[Andy Wozniak]

This patch does "seem" to fix the expanding bookmark folder issue described by Bug 454118. There is still some odd behaviour:

- with several bookmark folders plus google search in the bookmark toolbar, the search bar now takes up a much larger proportion of the toolbar, as compared to FF 3.0 This causes some toolbar bookmark folders to remain collapsed.

- when you make the FF window very narrow, all bookmark toolbar items are collapsed (excluded google searcg) as expected. But when the window is made wide again, the bookmark toolbar items remain collapsed.

Comment 9

[vezquex]

Heh, this bug doesn't exist if you put a separator between the bookmarks and the search box.

Comment 10

[vezquex]

(In reply to comment #9)
> Heh, this bug doesn't exist if you put a separator between the bookmarks and
> the search box.

Scratch that.

Comment 11

[Marco Bonardo [:mak]]

imho, you should do that only after "var spaceLeft = this.boxObject.width;" if spaceLeft is 0, since that's the only case where we fail (another element is taking away all the space)

And you could ask review to Mano to hear what are his ideas regard this.

Comment 12

[Marco Bonardo [:mak]]

oh, and add some comment to explain why you do that

Comment 13

[Dietrich Ayala (:dietrich)]

Not going to hold the 3.1 release for this.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Comment on attachment 337702 [details] [diff] [review]
patch for places\toolbar.xml

Not a real patch against trunk but worth having an answer from you Asaf.

Comment 16

[Asaf Romano (gone)]

Comment on attachment 337702 [details] [diff] [review]
patch for places\toolbar.xml

I cannot see any way this would make sense.

Comment 17

[Asaf Romano (gone)]

Attachment: patch

Comment 18

[Marco Bonardo [:mak]]

Mano, this only solves the startupcase, while does not solve comment 1 (minimize) and comment 3 (resize) cases

Comment 20

[Dietrich Ayala (:dietrich)]

Comment on attachment 344745 [details] [diff] [review]
patch 

removing review request, see comment #18.

Comment 24

[RC]

Annoying. As. Balls. *sigh*
I know 3.1 wasn't going to be stopped but I was hoping to see some action on it :\ yay. "Open browser > right click properties > click Done" fo' life!

Comment 25

[Andy Wozniak]

"Open browser > right click properties > click Done"

I'm confused how right click properties is possible.

Comment 26

[RC]

s /properties/customize/ :p

Comment 27

[RC]

So just so I understand Dietrich Ayala, in the 3.1 final release one will have to use the customize click on every launch to clear this issue?

Comment 28

[Brian Polidoro]

I gave another workaround in comment #3.

Comment 29

[RC]

(In reply to comment #28)
> I gave another workaround in comment #3.

Ok.. let me rephrase: So just so I understand Dietrich Ayala/Asaf Romano, in the 3.1 final release one will have
to right click and select a menu item on every launch to clear this issue?

Comment 30

[Luke Iliffe (Harlequin99)]

I managed to work around the issue by placing multiple fixed width spacers rather than a flexible space between the help menu and my bookmarks toolbar. Not very elegant, but on XP it seems to prevent the bookmarks toolbar from collapsing.

Comment 31

[Christian 'CeeJay' Jensen]

Reproduced in Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20090211 Shiretoko/3.1b3pre (.NET CLR 3.5.30729)

This is extremely annoying - I won't be upgrading from 3.0.x to 3.1 final until this is fixed.

Comment 32

[RC]

Agreed. This is a deal breaker for me too. I wouldn't hang out with someone who poked me in the eye every time we met.

Comment 33

[Nochum Sossonko [:Natch]]

Guys, what you are doing will likely lessen the chance of anyone trying to fix this. Mozilla is an open source software and thus anyone can contribute a fix here, including you. This is a technical _bug_ database, not a forum or feedback blog, please see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and stop commenting unless you wish to contribute a fix.

Comment 34

[Marco Bonardo [:mak]]

Mano, any eta on this?
couldn't we take a

var spaceLeft = this.boxObject.width;
if (spaceLeft == 0)
  this.childNodes.forEach(function(node) node.collapsed = false);

so that if another object cuts our width to 0 we  uncollapse and recalculate everything? that code would act only in such a case, so would be less heavy than doing that everytime (previous patch)

Comment 35

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

Attachment: patch

I don't think we need to block a fix for the startup case on also fixing the resize/minimize cases. I'm not even able to reproduce those, but the startup case affects everyone using this config.

This is a slight variation on Mano's attachment 344745 [details] [diff] [review] that also fixes the bug. The main difference is that it only defers the updateChevron calls rather than all of _init(). It's rather hacky to rely on MozAfterPaint, but I can't think of any better alternatives, and I'd like to fix this for 1.9.1.

Comment 36

[Marco Bonardo [:mak]]

(In reply to comment #35)
> I don't think we need to block a fix for the startup case on also fixing the
> resize/minimize cases. I'm not even able to reproduce those, but the startup
> case affects everyone using this config.

well i was instead able to reproduce that everytime on windows, quite annoying, what's the usecase of making that correct on startup if i can't then minimize or resize the browser window? By the way, if you can't reproduce in win let me know, so i can retry.

comment 34 could still be hacky like that, but should work everywhere causing a minimum impact.

Comment 37

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

Can you explain why comment 34 works? It doesn't make any sense to me... we already uncollapse all items in the loop just below it, no?

Comment 38

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

With my patch, minimizing the window doesn't cause any problems with the bookmarks toolbar as far as I can tell (Windows). Perhaps I'm doing something differently? My STR are:

1) Move bookmark toolbar items to the left of the location bar
2) restart. make sure bookmark toolbar items are all visible and not collapsed.
3) minimize window using the "_" button on the top right, then restore it by clicking the button in the task bar
4) make sure bookmark toolbar items are all visible and not collapsed.

I _can_ however reproduce the resize issue (comment 3).

Comment 39

[Marco Bonardo [:mak]]

(In reply to comment #37)
> Can you explain why comment 34 works? It doesn't make any sense to me... we
> already uncollapse all items in the loop just below it, no?

oh sorry i did not put the full change there, the issue is that we use this.boxObject.width, but when some other element push us it will be 0. So the idea is that is our width is pushed to 0 we uncollapse everything, calculate a new spaceLeft starting value, and restart to collapse. The full change would be

var spaceLeft = this.boxObject.width;
if (spaceLeft == 0) {
  this.childNodes.forEach(function(node) node.collapsed = false);
  spaceLeft = this.boxObject.width;
}

Comment 40

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

OK, and that fixes all the problems (startup/resize/minimize)? Sounds like we should get that in, then.

Comment 41

[Marco Bonardo [:mak]]

effectively something must be changed, minimize issue is no more reproducible (who knows what fixes that?), and the only working (fixing both startup and resize) workaround is now attachment 337702 [details] [diff] [review], that on the other side is a perf loss since it forces recalculation at every call.
The ideal fix would be that, but limited to affected cases (so only when there's some other element that pushes our width), dunno how that can be done...

So we can probably go on with mozAfterPaint, filing a bug on the remaining resize issue.

Comment 42

[Marco Bonardo [:mak]]

on the other side we could also simply set a min-width on hbox[type="places"] in places.css, that would avoid the complete shrunk of the toolbar.

Comment 43

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

(In reply to comment #41)
> The ideal fix would be that, but limited to affected cases (so only when
> there's some other element that pushes our width), dunno how that can be
> done...

Doesn't your suggestion in comment 34 do that?

Comment 44

[Marco Bonardo [:mak]]

(In reply to comment #43)
> (In reply to comment #41)
> > The ideal fix would be that, but limited to affected cases (so only when
> > there's some other element that pushes our width), dunno how that can be
> > done...
> 
> Doesn't your suggestion in comment 34 do that?

only on first resize when width is 0, not as expected though, in many cases width is not 0 but is some px (i'm testing with the most common case, icons without label). min-width on the other side looks working fine forcing a width for the toolbar.

Comment 46

[Marco Bonardo [:mak]]

Attachment: merged patches

dunno why i didn't thought about this before, but merging the 2 solutions could fix both issues.

Practically if the bar becomes smaller than 2* the chevron size (about 2 icons) it will start to recalculate everything till the bar comes back to the size it had on first paint, then it will revert to the default behavior. It won't uncollapse till that point, but it's an easy enough workaround for any user, and won't allow the bar to go to an unusable state (eg only the chevron).

Gavin could you test this?

Comment 48

[RS]

This Bug has been Open for a long time and every-time someone reports its marked as Duplicate - but there is no solution yet - is some one working to resolve this? I am not a developer otherwise would be glad to help.  Thanks for all the help anyways....

Comment 50

[ross]

As of 3.5b4 this bug is now manifesting whenever a window is opened.  This is now extremely annoying for me; please fix this before the final version launches.

Comment 52

[Peter]

I really wish a fix for this serious bug would be implemented.  I'm not a developer but it doesn't seem like it should be that difficult to fix.  I think the priority on this issue should be elevated.  JMHO.  Thanks for all the work you all do and sorry if this comment is inappropriate here.

Comment 55

[Marco Bonardo [:mak]]

Mano, Gavin, can we try to take at least one workaround for 3.5?

Comment 56

[Dietrich Ayala (:dietrich)]

customization is our friend, wanted+.

Comment 57

[RC]

This is still happening in the 3.5 preview :\ the whole launch>>right click>>customize>>ok shouldn't be muscle memory. I wish I could contribute more.

Comment 58

[u88484]

(In reply to comment #57)
> This is still happening in the 3.5 preview :\ the whole launch>>right
> click>>customize>>ok shouldn't be muscle memory. I wish I could contribute
> more.
That would be because the bug's status is assigned and not resolved or verified fixed ;)

No further comments are needed in this bug.  The devs know this bug exists.

Comment 63

[Gaurav Kumar]

Hey guys
Below I present a workaround. I have tested it in Firefox 3.5 Final in Windows Vista. Edit your userChrome.css file located in chrome folder in your profile. Add these two lines at the end.

/* Fix for Bookmarks Items Overflow */
#bookmarksBarContent .bookmark-item {visibility: visible !important;}

Thank you.

Comment 64

[hopson]

Tried Gaurav Kumar's workaround, also on Vista (Home) w/ FF3.5 (Japanese).
It is an improvement, but fundamentally the problem is not fixed.  The bookmarks are crowded together in the corner, overlapping so as to be unusable.  The easiest workaround for this is the one I've been using thus far for the original problem (i.e. we're not getting anywhere...), which is to open the Customize dialog.  Opening and then closing this dialog fixes the display problem.

Comment 66

[Alice0775 White]

[Workaround]:

bug447571 (Expand bookmarks toolbar) :: Add-ons for Firefox
https://addons.mozilla.org/en-US/firefox/addon/11325

Comment 70

[guanxi]

Alice White's add-on works for me. Thanks Alice!

As long as I'm posting: The problem I'm seeing is with the Bookmarks Toolbar Items placed on the Navigation Bar. It recurs every time I open a new window.

Comment 71

[jbMac]

I'll echo that Alice White's add-on works for me.  XP on 533Mhz PC.  This bug was the first thing I noticed when I upgraded to FF3.5 from FF2.  My menu(tiny menu), navigation buttons, bookmark items and URL are all on a single line.

Comment 72

[Perry R]

One more confirm of the fix from from Alice White's add-on. Win2k on 1.5Ghz PC. Only thing i noticed after upgrade from 3.0.11 -> 3.5. My bookmark toolbar items (and all other widgets) are in the main menu on a single line, i have none of the toolbars enabled.

Comment 76

[keith Worden]

Alice White's add-on works for me. Running 3.5 on Vista SP1.

Comment 81

[Will Pittenger]

An extension which resolves this problem is now available.  "bug447571" (https://addons.mozilla.org/en-US/firefox/addon/11325)

Comment 82

[Marco Bonardo [:mak]]

bug 382466 can most likely fix this in a less hacky way.

Comment 84

[Nochum Sossonko [:Natch]]

Should this be relonote'd?

Comment 86

[molsten]

I've not encountered this problem until today when I updated to FF3.5.2 from 3.0.13

When opening a new window my Bookmarks toolbar shows only half the icons, the rest are under a chevron list. 

On one machine (Vista SP2 - 1440x900) as you browse the icons seem to progressively show up on their own. 

My other machine (XP SP3 - 1024x600) it remains that way constantly.

Is there a bug in the toolbar's measure screen width code?

Comment 87

[Marco Bonardo [:mak]]

next Minefield nightly should contain bug 382466, it should fix this.
i'm going to resolve the bug, if you notice mibehaviors about this, feel free to reopen

Comment 91

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Marco, I don't think that the current behavior is a good solution. Even this particular bug is fixed but when you place the e.g. location bar right behind the bookmarks toolbar inside the menu toolbar the bookmarks have a much higher priority and will cause the location bar to shrink to somewhat 150px in width which makes it totally useless. Shall we file this as a new bug or is there already a bug?

Comment 92

[[:Cww]]

Triaging common issues and adding forum posts.

https://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&comments_parentId=379843&forumId=1
https://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&comments_parentId=380456&forumId=1
https://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&comments_parentId=380800&forumId=1
https://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&comments_parentId=381086&forumId=1
https://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&comments_parentId=382196&forumId=1
https://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&comments_parentId=382523&forumId=1
https://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&comments_parentId=382917&forumId=1

Comment 95

[[:Cww]]

Any chance of this making it in 1.9.1? (If not the full patch, just the part that fixes this specific annoyance)

Comment 96

[Marco Bonardo [:mak]]

(In reply to comment #95)
> Any chance of this making it in 1.9.1? (If not the full patch, just the part
> that fixes this specific annoyance)

there is not a part of it, we should take the full patch, i can't see anything bad in taking the patch, but it is still waiting 1.9.2 approval, and it's not exactly stability or crash related. I know it's annoying, but has a workaround, and that could be enough to take this small rewrite only on 1.9.2+

Comment 97

[Marco Bonardo [:mak]]

(In reply to comment #91)
> Marco, I don't think that the current behavior is a good solution. Even this
> particular bug is fixed but when you place the e.g. location bar right behind
> the bookmarks toolbar inside the menu toolbar the bookmarks have a much higher
> priority and will cause the location bar to shrink to somewhat 150px in width
> which makes it totally useless.

as pointed on irc that sounds like bug 408263 or bug 448399

Comment 99

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090831 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20090831044843

Comment 100

[[:Cww]]

(In reply to comment #97)

This can look like dataloss for some users and definitely looks buggy.  I personally don't think an extension as a workaround is much of a workaround at all.  If it's a low-risk patch, I think it should be taken.

If it's not low-risk or there are other complications, I'll be OK with leaving it but I think we should relnote.

Comment 101

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #100)
> This can look like dataloss for some users and definitely looks buggy.  I
> personally don't think an extension as a workaround is much of a workaround at
> all.  If it's a low-risk patch, I think it should be taken.

You should ask on bug 382466 since there is the patch.

Comment 102

[Daniel Veditz [:dveditz]]

Given comment 96 (no small "band-aide" fix) and the fact that by time this gets reasonable testing on the 1.9.2 branch we'll be close to switching most 3.5 users to 3.6 we're not going to block on this bug for a 3.5.x update.

Comment 105

[u209627]

So this will not going to be fixed in 3.5.4? Because I updated to 3.5.4 today and this bug still occurs.

Comment 106

[Shawn Wilsher :sdwilsh]

(In reply to comment #105)
> So this will not going to be fixed in 3.5.4? Because I updated to 3.5.4 today
> and this bug still occurs.
This will be fixed in Firefox 3.6 (beta 1, when it comes out later this week) and will not be fixed in any Firefox 3.5 release (per status1.9.1 being wontfix).

Comment 111

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv

Comment 117

[Siddhartha Dugar [:sdrocking]]

Is this bug really fixed? I still see my bookmarks toolbar items collapsing.
For users who are still facing this use https://addons.mozilla.org/en-US/firefox/addon/right-aligned-bookmarks-bar/

Comment 118

[Marco Bonardo [:mak]]

(In reply to sdrocking from comment #117)
> Is this bug really fixed? I still see my bookmarks toolbar items collapsing.

Try searching, there's for sure another bug still open for your specific case (don't recall the exact bug number atm). This old bug fixed another outstanding case.