Closed Bug 37766 Opened 24 years ago Closed 24 years ago

minimising personal and navigation toolbar causes ui horkage

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: doronr, Assigned: bugs)

References

Details

(Whiteboard: [nsbeta2+] [will be minus on 6/15]) 

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
Assignee: bdonohoe → trudelle
Component: User Interface: Design Feedback → XP Toolkit/Widgets
QA Contact: mpt → jrgm
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.
Keywords: regression
OS: Windows 98 → All
Hardware: PC → All
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?
Assignee: trudelle → ben
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?
Severity: normal → major
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...
Target Milestone: --- → M17
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).
Severity: major → normal
Depends on: 35181
Move to M20 target milestone.
Target Milestone: M17 → M21
*** 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).
Keywords: regression → nsbeta2
[nsbeta2-]
Whiteboard: [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.
Whiteboard: [nsbeta2-]
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?
Whiteboard: [nsbeta2+] [will be minus on 6/15]
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.
Status: NEW → RESOLVED
Closed: 24 years ago
Depends on: 41145
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
EEeeettzzz Baaaaack.... Linux M16 *FINAL*! Navigation toolbar, and Composer tb.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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)
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Yes, it is fixed in the trunk, but, my bad, I should have release noted this
point. I'll do that now.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.