Minimising the personal and navigation toolbar causes ui horkage. The minimised states are too thick. You can also rearrange the toolbars like this, probably not a bug. seen on 2000050111 win98 mozilla build

That's a bug alright. It happens on Mac OS, too. It's not a design issue, though... ;) Reassigning to XP Toolkit/Widgets

Marking Platform/OS as All/All based on last comment. This only happens with the 0501 builds and (presumably) later. At least you can unminimize them ;-}. If only the personal toolbar is minimized, that works as it did before, but when the navigation toolbar is minimized, the UI element containing the twisty is as tall as the original toolbar; the equivalent element for the personal toolbar gets the same height so long as the navigation toolbar is minimized.

Let's just call the ability to reorder them in this way an unintended feature, since it is the only way your'e going to be able to reorder them in this release cycle. I see very minor horkage, but the minimized grippies are way too tall. ben, is this more of your style sheet goodness?

On today's linux ( which crashes all the time doing anything), if I minimize a toolbar...poof!..It's gone..and there is no way of getting it back(I see a blank white space).

Same blank whitespace on Mac OS build 2000050510. Clicking where the grippies used to be doesn't do anything. Turning the toolbars off, then on again with the menu doesn't fix the problem. Eww, this is yucky. Highly visible, and a regression so it's probably easily fixable. nsbeta2, anyone?

Here's another bizzare aspect to this I found today. Matthew beat me to my first comments. :-} I attempted to bring back the personal and navigational toolbars through the menu. Nothing but grey space. Then, when I gripped the scrollbar to scroll down the page, the scrollbar stayed gripped even after I let up on the mouse button and moved off the scrollbar. I could scroll up and down the page without using the scrollbar. All I was doing was moving the mouse arrow up and down in the middle of the page. Clicking a text box allowed me to enter this text, but did not change the state of the mouse/scrollbar -- I can scroll moving the mouse in the center of the page even after entering text. Obviously, we'd expect the side scrollbar to quit scrolling when one lets up on the mouse button. What we're getting is the scrollbar continuing to scroll after the mouse button is left up. I'm running M15, Mac OS 9.0.4, MRJ 2.2, and carbon libs 1.0.4.

Workaround for those of you who have lost your toolbars: quit Mozilla, trash the localstore.rdf file in your profile folder, and restart Mozilla. Otherwise you'll be toolbar-less forever.

I didn't do what Matthew suggested at 6:48. Instead, I trashed the "prefs.js" file in my Mozilla user profile. I then got my toolbars back. And the scrolling bug I reported disappeared as well. Go figure!

setting mileston for Don...

Build 2000050808. Tried trashing prefs.js as Kurt suggested 2000-05-07 12:50 - still a white void. Then tried Matthew's suggestion 2000-05-07 06:48 - this worked. Highly prominent regression - especially with the sidebar not collapsing properly either!

Okay -- currently the behaviour of this bug is masked by bug #35181, so let's not morph this bug into a duplicate of that one. This bug is "The minimised states are too thick" while bug #35181 is "toolbars disappear forever when collapsed". The correct workaround to recover your toolbars is noted in bug #35181 (which is either delete or do a small edit on localstore.rdf). Deleting prefs.js is not the workaround (and I can't imagine why this seemed to work for Kurt Weinschenker).

Move to M20 target milestone.

*** Bug 40842 has been marked as a duplicate of this bug. ***

would be nice to have this for beta2 b/c of visibility...

Say, ben. You have min-height: defined for .toolbar-primary and .toolbar-standard -- removing the min-height: (which is 47px) largely fixes this problem. There are some remaining issues with the appearance of the .collapsed-tray that need to be resolved, and with the persistence of the contents of the .collapsed-tray (i.e., on restart, the toolbars are collapsed, but they are stacked vertically in the toolbox.internal-box, instead of horizontally in the toolbox.collapsed-tray). Adding nsbeta2 -- this looks like a simple fix (if not perfect), and it's just too glaring a visual defect to ship with the PR2 (just collapse the toolbars at the top and bottom of the browser to see the effect).

[nsbeta2-]

I just noticed a news posting in n.p.m.builds that contains a screen shot, and Gerv's reply pointing to this bug and mentioning the [nsbeta2-]. Based on the high visibility of this, I disagree with the [nsbeta2-] designation. If beta2 goes out with this bug in its current state, it will be just another thing that makes people laugh at the Netscape PRs. I suggest to clear the Status Whiteboard for re-evaluation. Anyone out there to agree?

I tend to agree with that. removing nsbeta2- designation for reconsideration. peter, phil, jan, anyone PDT: this is a high-visiblity bug with a seemingly low- risk solution. If John's small change does indeed fix this, I see no reason not to go ahead with it for PR2. I also assume Ben knows how to fix this (this works in his classic skin perfectly, btw), but this probably just isn't on his plate yet.

Gentlemen, the focus of PR2 is not UI polish. It is feature complete and stability. Though, yes, we should try to fix this, we cannot hold beta2 for this if ben does not have time to get to it. His [nsbeta2+] bugs come first. As a compromise, I will put this on the [nsbeta2+] [will be minus on 6/15] radar. If ben can complete his "must fix" bugs for beta2, and then get to this by 6/15 ...great! Or maybe a net community person can get this code done?

I agree, this is not a beta2 blocker. This was in beta1 as well and there was no outcry. Now, if this is fixed in the the classic skin, can someone look at the differences and try? This should not be too hard.

Jan - fair enough. thanks. I'll take a look at this in a little while; I imagine it's not too difficult.

style change checked in, fixed.

this wfm now on linux, win98 and win2k (60609). waiting on mac verification. meanwhile, i've split off bug 41679 to handle the toolbar rearranging issue.

verified, Asa saw it working on Mac.

EEeeettzzz Baaaaack.... Linux M16 *FINAL*! Navigation toolbar, and Composer tb.

erm, I believe it's "back" because it never got fixed in the m16 branch...it's still fine in m17. (reopen if i'm wrong here)

Yes, it is fixed in the trunk, but, my bad, I should have release noted this point. I'll do that now.