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

VERIFIED FIXED in Firefox 3.7a1

Status

()

Firefox
Bookmarks & History
P3
normal
VERIFIED FIXED
9 years ago
3 years ago

People

(Reporter: Stephen Walker, Unassigned)

Tracking

({common-issue+, regression})

Trunk
Firefox 3.7a1
common-issue+, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3.5 -
wanted-firefox3.5 +
wanted-firefox3.6 +

Firefox Tracking Flags

(status1.9.2 beta1-fixed, blocking1.9.1 -, status1.9.1 wontfix)

Details

(Whiteboard: [fixed by bug 382466][has workaround])

Attachments

(4 obsolete attachments)

(Reporter)

Description

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

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

Updated

9 years ago
Duplicate of this bug: 454118

Comment 3

9 years ago
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.
Flags: wanted-firefox3.1?
Flags: blocking-firefox3.1?

Comment 4

9 years ago
Created attachment 337702 [details] [diff] [review]
patch for places\toolbar.xml

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

Comment 5

9 years ago
I suspect this bug is a duplicate of bug 427280.

Updated

9 years ago
Summary: Bug 443734 broke bookmarks expansion when all items are put on a single toolbar → bookmarks expansion broken when all items are put on a single toolbar

Updated

9 years ago

Updated

9 years ago
Duplicate of this bug: 427280

Comment 7

9 years ago
This patch works for me.

Comment 8

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

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

Comment 10

9 years ago
(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.
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.
oh, and add some comment to explain why you do that
Not going to hold the 3.1 release for this.
Flags: wanted-firefox3.1?
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
Priority: -- → P3
Attachment #337702 - Flags: review?(mano)
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.

Updated

9 years ago
Duplicate of this bug: 461165
Comment on attachment 337702 [details] [diff] [review]
patch for places\toolbar.xml

I cannot see any way this would make sense.
Attachment #337702 - Flags: review?(mano) → review-
Created attachment 344745 [details] [diff] [review]
patch
Assignee: nobody → mano
Attachment #337702 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #344745 - Flags: review?(dietrich)
Mano, this only solves the startupcase, while does not solve comment 1 (minimize) and comment 3 (resize) cases

Updated

9 years ago
Duplicate of this bug: 461790
Comment on attachment 344745 [details] [diff] [review]
patch 

removing review request, see comment #18.
Attachment #344745 - Flags: review?(dietrich)
Duplicate of this bug: 462749

Updated

9 years ago
Duplicate of this bug: 456925

Updated

9 years ago
Duplicate of this bug: 467286

Comment 24

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

9 years ago
"Open browser > right click properties > click Done"

I'm confused how right click properties is possible.

Comment 26

9 years ago
s /properties/customize/ :p

Comment 27

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

9 years ago
I gave another workaround in comment #3.

Comment 29

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

Updated

9 years ago
Target Milestone: --- → Firefox 3.1
Whiteboard: [needs new patch]
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

9 years ago
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.
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.
Whiteboard: [needs new patch] → [needs new patch][see comment 33 before commenting]
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)

Updated

9 years ago
Blocks: 436546
Created attachment 363545 [details] [diff] [review]
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.
Attachment #344745 - Attachment is obsolete: true
Attachment #363545 - Flags: review?(mano)
(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.
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?
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).
(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;
}
OK, and that fixes all the problems (startup/resize/minimize)? Sounds like we should get that in, then.
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.
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.
(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?
(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.
Duplicate of this bug: 481912
Target Milestone: Firefox 3.1 → ---
Created attachment 367231 [details] [diff] [review]
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?
Attachment #367231 - Flags: review?(gavin.sharp)

Updated

8 years ago
Duplicate of this bug: 490624

Comment 48

8 years ago
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....
Duplicate of this bug: 491139

Comment 50

8 years ago
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.
Duplicate of this bug: 491222

Comment 52

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

Updated

8 years ago
Duplicate of this bug: 493985

Updated

8 years ago
Duplicate of this bug: 489525
Mano, Gavin, can we try to take at least one workaround for 3.5?
Flags: wanted-firefox3.5+ → wanted-firefox3.6+

Updated

8 years ago
Flags: wanted-firefox3.5?
customization is our friend, wanted+.
Flags: wanted-firefox3.5? → wanted-firefox3.5+

Updated

8 years ago
Whiteboard: [needs new patch][see comment 33 before commenting] → [needs review gaving/mano][has workaround][see comment 33 before commenting]

Comment 57

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

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

Updated

8 years ago
Blocks: 499088
Duplicate of this bug: 499468
Duplicate of this bug: 499503
Duplicate of this bug: 497926

Updated

8 years ago
Duplicate of this bug: 500808
Flags: wanted1.9.1.x?

Comment 63

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

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

Updated

8 years ago
Duplicate of this bug: 501571

Comment 66

8 years ago
[Workaround]:

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

Updated

8 years ago
Duplicate of this bug: 501600

Updated

8 years ago
Duplicate of this bug: 501882
Duplicate of this bug: 501849

Comment 70

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

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

8 years ago
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.
Duplicate of this bug: 503503

Updated

8 years ago
Duplicate of this bug: 504002

Updated

8 years ago
Duplicate of this bug: 504321

Updated

8 years ago
Flags: blocking-firefox3.6?

Comment 76

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

Updated

8 years ago
Duplicate of this bug: 504558

Updated

8 years ago
Duplicate of this bug: 506529
Duplicate of this bug: 506568
Duplicate of this bug: 506594

Comment 81

8 years ago
An extension which resolves this problem is now available.  "bug447571" (https://addons.mozilla.org/en-US/firefox/addon/11325)
bug 382466 can most likely fix this in a less hacky way.

Updated

8 years ago
Duplicate of this bug: 508845
Should this be relonote'd?
Keywords: common-issue?
status1.9.1: --- → ?
Flags: wanted1.9.1.x?
Duplicate of this bug: 510006

Updated

8 years ago
Depends on: 382466

Comment 86

8 years ago
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?
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
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [needs review gaving/mano][has workaround][see comment 33 before commenting] → [fixed by bug 382466][has workaround]
Target Milestone: --- → Firefox 3.7

Updated

8 years ago
Attachment #363545 - Attachment is obsolete: true
Attachment #363545 - Flags: review?(mano)

Updated

8 years ago
Attachment #367231 - Attachment is obsolete: true
Attachment #367231 - Flags: review?(gavin.sharp)

Updated

8 years ago
Assignee: mano → nobody

Updated

8 years ago
Duplicate of this bug: 499088

Updated

8 years ago
Duplicate of this bug: 511619

Updated

8 years ago
Duplicate of this bug: 512178
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?
Target Milestone: Firefox 3.7 → Firefox 3.7a1

Comment 92

8 years ago
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
Keywords: common-issue? → common-issue+
Duplicate of this bug: 513209
Duplicate of this bug: 513415

Comment 95

8 years ago
Any chance of this making it in 1.9.1? (If not the full patch, just the part that fixes this specific annoyance)
(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+
(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
Duplicate of this bug: 514161
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
Status: RESOLVED → VERIFIED
Flags: blocking-firefox3.6?

Comment 100

8 years ago
(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.
blocking1.9.1: --- → ?
(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.
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.
blocking1.9.1: ? → -
status1.9.1: ? → wontfix

Updated

8 years ago
Duplicate of this bug: 514940

Updated

8 years ago
status1.9.2: --- → beta1-fixed
Duplicate of this bug: 520419

Comment 105

8 years ago
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.
(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).
Duplicate of this bug: 527415

Updated

8 years ago
Duplicate of this bug: 497131

Updated

8 years ago
Duplicate of this bug: 499492

Updated

8 years ago
Duplicate of this bug: 526716
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
Duplicate of this bug: 537895
Duplicate of this bug: 539103
Duplicate of this bug: 539958

Updated

8 years ago
Blocks: 444066

Updated

8 years ago
Duplicate of this bug: 538031
Duplicate of this bug: 539103
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/
(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.
You need to log in before you can comment on or make changes to this bug.