Last Comment Bug 447571 - bookmarks expansion broken when all items are put on a single toolbar
: bookmarks expansion broken when all items are put on a single toolbar
Status: VERIFIED FIXED
[fixed by bug 382466][has workaround]
: common-issue+, regression
Product: Firefox
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: Trunk
: All All
: P3 normal with 27 votes (vote)
: Firefox 3.7a1
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 427280 454118 456925 461165 461790 462749 467286 481912 489525 490624 491139 491222 493985 497131 497926 499088 499468 499492 499503 500808 501571 501600 501849 501882 503503 504002 504321 504558 506529 506568 506594 508845 510006 511619 512178 513209 513415 514161 514940 520419 526716 527415 537895 538031 539958 (view as bug list)
Depends on: 382466
Blocks: 436546 444066 499088
  Show dependency treegraph
 
Reported: 2008-07-22 21:40 PDT by Stephen Walker
Modified: 2014-03-17 19:34 PDT (History)
74 users (show)
dietrich: blocking‑firefox3.5-
dietrich: wanted‑firefox3.5+
dietrich: wanted‑firefox3.6+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
beta1-fixed
-
wontfix


Attachments
patch for places\toolbar.xml (1.88 KB, patch)
2008-09-09 11:39 PDT, Alice0775 White
asaf: review-
Details | Diff | Splinter Review
patch (2.17 KB, patch)
2008-10-25 05:38 PDT, Mano (::mano, needinfo? for any questions; not reading general bugmail)
no flags Details | Diff | Splinter Review
patch (2.02 KB, patch)
2009-02-22 00:50 PST, :Gavin Sharp [email: gavin@gavinsharp.com]
no flags Details | Diff | Splinter Review
merged patches (3.00 KB, patch)
2009-03-13 08:49 PDT, Marco Bonardo [::mak]
no flags Details | Diff | Splinter Review

Description Stephen Walker 2008-07-22 21:40:01 PDT
[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 2008-08-24 14:13:53 PDT
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 2 Brian Polidoro 2008-09-09 10:01:41 PDT
*** Bug 454118 has been marked as a duplicate of this bug. ***
Comment 3 Brian Polidoro 2008-09-09 10:07:03 PDT
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 2008-09-09 11:39:11 PDT
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 Ken Takusagawa 2008-09-10 11:55:46 PDT
I suspect this bug is a duplicate of bug 427280.
Comment 6 Dão Gottwald [:dao] 2008-09-10 12:12:11 PDT
*** Bug 427280 has been marked as a duplicate of this bug. ***
Comment 7 Ken Takusagawa 2008-09-11 13:48:50 PDT
This patch works for me.
Comment 8 Andy Wozniak 2008-09-11 16:28:58 PDT
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 2008-09-24 21:51:10 PDT
Heh, this bug doesn't exist if you put a separator between the bookmarks and the search box.
Comment 10 vezquex 2008-09-24 23:54:34 PDT
(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] 2008-10-01 17:18:35 PDT
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] 2008-10-01 17:20:33 PDT
oh, and add some comment to explain why you do that
Comment 13 Dietrich Ayala (:dietrich) 2008-10-20 14:40:47 PDT
Not going to hold the 3.1 release for this.
Comment 14 Henrik Skupin (:whimboo) 2008-10-20 14:54:53 PDT
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 15 Marco Bonardo [::mak] 2008-10-22 15:01:17 PDT
*** Bug 461165 has been marked as a duplicate of this bug. ***
Comment 16 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2008-10-25 04:34:58 PDT
Comment on attachment 337702 [details] [diff] [review]
patch for places\toolbar.xml

I cannot see any way this would make sense.
Comment 17 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2008-10-25 05:38:41 PDT
Created attachment 344745 [details] [diff] [review]
patch
Comment 18 Marco Bonardo [::mak] 2008-10-25 09:59:32 PDT
Mano, this only solves the startupcase, while does not solve comment 1 (minimize) and comment 3 (resize) cases
Comment 19 Brian Polidoro 2008-10-27 14:29:19 PDT
*** Bug 461790 has been marked as a duplicate of this bug. ***
Comment 20 Dietrich Ayala (:dietrich) 2008-11-01 18:52:26 PDT
Comment on attachment 344745 [details] [diff] [review]
patch 

removing review request, see comment #18.
Comment 21 Ria Klaassen (not reading all bugmail) 2008-11-02 10:14:20 PST
*** Bug 462749 has been marked as a duplicate of this bug. ***
Comment 22 Marco Bonardo [::mak] 2008-11-08 07:31:03 PST
*** Bug 456925 has been marked as a duplicate of this bug. ***
Comment 23 Jesse Ruderman 2008-11-30 16:28:15 PST
*** Bug 467286 has been marked as a duplicate of this bug. ***
Comment 24 RC 2008-12-08 16:10:24 PST
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 2008-12-08 16:30:56 PST
"Open browser > right click properties > click Done"

I'm confused how right click properties is possible.
Comment 26 RC 2008-12-08 21:12:10 PST
s /properties/customize/ :p
Comment 27 RC 2008-12-09 18:15:12 PST
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 2008-12-09 18:37:19 PST
I gave another workaround in comment #3.
Comment 29 RC 2008-12-09 18:51:15 PST
(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) 2008-12-12 03:05:56 PST
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 2009-02-11 18:10:59 PST
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 2009-02-11 18:51:08 PST
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] 2009-02-11 18:57:22 PST
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] 2009-02-13 05:31:58 PST
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: gavin@gavinsharp.com] 2009-02-22 00:50:31 PST
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.
Comment 36 Marco Bonardo [::mak] 2009-02-22 16:35:40 PST
(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: gavin@gavinsharp.com] 2009-02-23 01:31:36 PST
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: gavin@gavinsharp.com] 2009-02-23 01:36:20 PST
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] 2009-02-23 05:43:05 PST
(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: gavin@gavinsharp.com] 2009-02-23 15:30:40 PST
OK, and that fixes all the problems (startup/resize/minimize)? Sounds like we should get that in, then.
Comment 41 Marco Bonardo [::mak] 2009-02-24 06:03:06 PST
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] 2009-02-24 06:10:03 PST
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: gavin@gavinsharp.com] 2009-02-25 10:22:24 PST
(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] 2009-02-25 11:03:05 PST
(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 45 Ria Klaassen (not reading all bugmail) 2009-03-07 02:03:11 PST
*** Bug 481912 has been marked as a duplicate of this bug. ***
Comment 46 Marco Bonardo [::mak] 2009-03-13 08:49:50 PDT
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?
Comment 47 Marco Bonardo [::mak] 2009-04-29 07:28:19 PDT
*** Bug 490624 has been marked as a duplicate of this bug. ***
Comment 48 RS 2009-05-01 16:50:01 PDT
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 49 Ria Klaassen (not reading all bugmail) 2009-05-03 12:29:50 PDT
*** Bug 491139 has been marked as a duplicate of this bug. ***
Comment 50 ross 2009-05-03 16:41:22 PDT
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 51 Nochum Sossonko [:Natch] 2009-05-03 22:40:46 PDT
*** Bug 491222 has been marked as a duplicate of this bug. ***
Comment 52 Peter 2009-05-12 01:42:40 PDT
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 53 Brian Polidoro 2009-05-20 11:38:22 PDT
*** Bug 493985 has been marked as a duplicate of this bug. ***
Comment 54 Brian Polidoro 2009-05-20 11:38:51 PDT
*** Bug 489525 has been marked as a duplicate of this bug. ***
Comment 55 Marco Bonardo [::mak] 2009-05-26 02:59:31 PDT
Mano, Gavin, can we try to take at least one workaround for 3.5?
Comment 56 Dietrich Ayala (:dietrich) 2009-05-26 16:48:32 PDT
customization is our friend, wanted+.
Comment 57 RC 2009-06-08 19:18:55 PDT
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 2009-06-09 04:04:22 PDT
(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 59 Ria Klaassen (not reading all bugmail) 2009-06-20 09:45:02 PDT
*** Bug 499468 has been marked as a duplicate of this bug. ***
Comment 60 Ria Klaassen (not reading all bugmail) 2009-06-21 01:10:19 PDT
*** Bug 499503 has been marked as a duplicate of this bug. ***
Comment 61 (mostly gone) XtC4UaLL [:xtc4uall] 2009-06-23 15:19:21 PDT
*** Bug 497926 has been marked as a duplicate of this bug. ***
Comment 62 Jesse Ruderman 2009-06-26 15:41:06 PDT
*** Bug 500808 has been marked as a duplicate of this bug. ***
Comment 63 Gaurav Kumar 2009-06-30 10:01:14 PDT
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 2009-06-30 18:57:21 PDT
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 65 Kevin Brosnan 2009-06-30 22:02:21 PDT
*** Bug 501571 has been marked as a duplicate of this bug. ***
Comment 66 Alice0775 White 2009-07-01 00:28:49 PDT
[Workaround]:

bug447571 (Expand bookmarks toolbar) :: Add-ons for Firefox
https://addons.mozilla.org/en-US/firefox/addon/11325
Comment 67 Kevin Brosnan 2009-07-01 01:27:05 PDT
*** Bug 501600 has been marked as a duplicate of this bug. ***
Comment 68 Mardeg 2009-07-01 23:54:17 PDT
*** Bug 501882 has been marked as a duplicate of this bug. ***
Comment 69 Ria Klaassen (not reading all bugmail) 2009-07-02 01:19:01 PDT
*** Bug 501849 has been marked as a duplicate of this bug. ***
Comment 70 guanxi 2009-07-03 08:50:15 PDT
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 2009-07-09 10:11:52 PDT
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 2009-07-09 19:55:56 PDT
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 73 :Gavin Sharp [email: gavin@gavinsharp.com] 2009-07-13 11:05:47 PDT
*** Bug 503503 has been marked as a duplicate of this bug. ***
Comment 74 [:Cww] 2009-07-13 18:49:49 PDT
*** Bug 504002 has been marked as a duplicate of this bug. ***
Comment 75 Mardeg 2009-07-15 08:02:14 PDT
*** Bug 504321 has been marked as a duplicate of this bug. ***
Comment 76 keith Worden 2009-07-16 03:10:06 PDT
Alice White's add-on works for me. Running 3.5 on Vista SP1.
Comment 77 Kevin Brosnan 2009-07-16 07:07:35 PDT
*** Bug 504558 has been marked as a duplicate of this bug. ***
Comment 78 Mardeg 2009-07-26 06:04:00 PDT
*** Bug 506529 has been marked as a duplicate of this bug. ***
Comment 79 Ria Klaassen (not reading all bugmail) 2009-07-26 13:06:49 PDT
*** Bug 506568 has been marked as a duplicate of this bug. ***
Comment 80 Ria Klaassen (not reading all bugmail) 2009-07-27 02:07:46 PDT
*** Bug 506594 has been marked as a duplicate of this bug. ***
Comment 81 Will Pittenger 2009-08-02 23:31:06 PDT
An extension which resolves this problem is now available.  "bug447571" (https://addons.mozilla.org/en-US/firefox/addon/11325)
Comment 82 Marco Bonardo [::mak] 2009-08-04 16:32:02 PDT
bug 382466 can most likely fix this in a less hacky way.
Comment 83 [:Cww] 2009-08-06 10:31:57 PDT
*** Bug 508845 has been marked as a duplicate of this bug. ***
Comment 84 Nochum Sossonko [:Natch] 2009-08-06 10:35:06 PDT
Should this be relonote'd?
Comment 85 Henrik Skupin (:whimboo) 2009-08-12 10:51:38 PDT
*** Bug 510006 has been marked as a duplicate of this bug. ***
Comment 86 molsten 2009-08-14 00:20:36 PDT
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] 2009-08-14 01:31:25 PDT
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 88 Marco Bonardo [::mak] 2009-08-14 01:53:36 PDT
*** Bug 499088 has been marked as a duplicate of this bug. ***
Comment 89 Mardeg 2009-08-20 04:26:31 PDT
*** Bug 511619 has been marked as a duplicate of this bug. ***
Comment 90 Mardeg 2009-08-23 15:25:45 PDT
*** Bug 512178 has been marked as a duplicate of this bug. ***
Comment 91 Henrik Skupin (:whimboo) 2009-08-23 15:41:27 PDT
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 93 Ria Klaassen (not reading all bugmail) 2009-08-28 05:51:06 PDT
*** Bug 513209 has been marked as a duplicate of this bug. ***
Comment 94 Ria Klaassen (not reading all bugmail) 2009-08-29 03:05:13 PDT
*** Bug 513415 has been marked as a duplicate of this bug. ***
Comment 95 [:Cww] 2009-09-01 11:15:59 PDT
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] 2009-09-01 11:29:38 PDT
(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] 2009-09-01 16:25:14 PDT
(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 98 Ria Klaassen (not reading all bugmail) 2009-09-02 08:10:19 PDT
*** Bug 514161 has been marked as a duplicate of this bug. ***
Comment 99 Henrik Skupin (:whimboo) 2009-09-02 09:17:45 PDT
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] 2009-09-02 13:45:27 PDT
(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) 2009-09-02 14:03:20 PDT
(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] 2009-09-02 15:44:28 PDT
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 103 Dâniel Fraga 2009-09-06 19:00:41 PDT
*** Bug 514940 has been marked as a duplicate of this bug. ***
Comment 104 Ria Klaassen (not reading all bugmail) 2009-10-04 00:18:59 PDT
*** Bug 520419 has been marked as a duplicate of this bug. ***
Comment 105 Dâniel Fraga 2009-10-28 11:11:33 PDT
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 2009-10-28 11:17:22 PDT
(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 107 Ria Klaassen (not reading all bugmail) 2009-11-09 03:51:37 PST
*** Bug 527415 has been marked as a duplicate of this bug. ***
Comment 108 Kevin Brosnan 2009-11-11 09:20:29 PST
*** Bug 497131 has been marked as a duplicate of this bug. ***
Comment 109 Kevin Brosnan 2009-11-11 09:20:35 PST
*** Bug 499492 has been marked as a duplicate of this bug. ***
Comment 110 Kevin Brosnan 2009-11-11 09:21:07 PST
*** Bug 526716 has been marked as a duplicate of this bug. ***
Comment 111 Gervase Markham [:gerv] 2009-11-26 05:49:25 PST
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 112 Ria Klaassen (not reading all bugmail) 2010-01-05 04:17:48 PST
*** Bug 537895 has been marked as a duplicate of this bug. ***
Comment 113 Jim Jeffery not reading bug-mail 1/2/11 2010-01-11 15:36:37 PST
*** Bug 539103 has been marked as a duplicate of this bug. ***
Comment 114 Ria Klaassen (not reading all bugmail) 2010-01-15 11:16:09 PST
*** Bug 539958 has been marked as a duplicate of this bug. ***
Comment 115 Marco Bonardo [::mak] 2010-01-25 17:25:34 PST
*** Bug 538031 has been marked as a duplicate of this bug. ***
Comment 116 Jim Jeffery not reading bug-mail 1/2/11 2010-01-27 04:39:31 PST
*** Bug 539103 has been marked as a duplicate of this bug. ***
Comment 117 Siddhartha Dugar [:sdrocking] 2011-09-15 10:54:35 PDT
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] 2011-09-19 13:51:44 PDT
(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.

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