Closed Bug 35181 Opened 24 years ago Closed 24 years ago

Using grippy to collapse toolbars completely hides them (disappear vanish)

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: bugs)

References

Details

(Keywords: regression, relnote, Whiteboard: [dogfood+])

This surely must be a duplicate, but I couldn't find it.

Win98SE
Build ID: 20000040808 [latest Win32 nightly build]

Steps to reproduce:
(1) Click on nearly any grippie in the browser, including the toolbars at the 
top, the toolbars in Mail, the toolbars in Preferences, the toolbars in sidebar 
Customize.  So far the only toolbar/grippie I've found that doesn't produce 
this bug is the taskbar.

Expected Results:  a thin bar appears with a smaller grippie that, if pressed, 
will return the toolbar to its previous (larger) state.

Actual Results:  The toolbar hides as usual, but rather than producing a thin 
bar with a grippie that can again be pressed to show the toolbar, the toolbar 
just entirely disappears.  As of now I have not discovered a way to get it back.

I believe there is more to this problem than I'm reporting.  For example, after 
I hid both of the browser toolbars at the top, a thin gray bar (with nothing on 
it, perhaps this is what was under the buttons?) is still visible.  Going to 
View | Navigation Toolbar had no effect except to check and uncheck that menu 
item, but clicking Personal Toolbar on the same menu hid and showed the gray 
strip.

This is a regression from yesterday's Win32 nightly build.
changing component to more appropriate XP Toolkit/Widgets, as problem deals 
specifically with toolbars.
Component: Browser-General → XP Toolkit/Widgets
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ugh! I hate this! I'm marking this as confirmed and voting for it. Beat this bug
into the ground for me =)

Build ID: 2000040808 (too many 0's in previous build ID too, this isnt the year
20000, even if that would be neat)
Oops, sorry bout that build ID.  Silly me, 20000040808 doesn't come until M30.  
Just kidding =)

In any event, anyone know what may be causing this bug?  If it hadn't been for 
the taskbar grippie working, I'd say it was a problem with the general 
grippie/toolbar widget itself.  The problem must be centralized somewhere 
though.  Any ideas?

reassigning to component owner, changing QA
Assignee: asadotzler → trudelle
QA Contact: jelwell → jrgm
Thanks. This is XP -- mac, win2k and linux from apr 08.

(By the way, a workaround (to recover the grippies) is 'File->New Navigator 
Window' -- this will show the toolbar grippies on the new window in the closed 
state. You can then open the toolbars to show the icons and menus, etc.)

Note: the taskbar is not enclosed in a toolbox, while the navigation and 
personal toolbars are enclosed in a toolbox. 

I think that hyatt's change to global.css to fix the double sidebar from 
yesterday may be behind this change in toolbar behaviour.
OS: Windows 98 → All
Hardware: PC → All
*** Bug 35226 has been marked as a duplicate of this bug. ***
reproduced in today's verfication build on Win98, updating summary for accuracy,
assigning to evaughan as p3 for m17.  Who marked this as blocker severity, and
why?  Since there is no comment, and there doesn't seem to be any way this could
be a blocker, I'm also changing severity to minor.
Assignee: trudelle → evaughan
Severity: blocker → minor
Summary: Using grippie to hide toolbars completely closes them → Using grippie to collapse toolbars completely hides them
Target Milestone: --- → M17
Not Eric's.  Ben can fix.  It's all style.
Assignee: evaughan → ben
added regression kw which should have been there earlier
Keywords: regression
*** Bug 35342 has been marked as a duplicate of this bug. ***
This bug breaks the workaround for bug 32120.
*** Bug 35370 has been marked as a duplicate of this bug. ***
This also applies to mailnews -- the address to:, from:, etc.


Collapse message header area; arrow missing to uncollapse

2000-04-10-09-m15 win32 build

1) Open mail
2) Select a message
3) Contents displayed in message pane.  Header area (date, to, cc:, etc) 
displayed also
4) Click on the arrow toggle to collapse the to: header area

actual result:  There is no longer an arrow to uncollapse the header area to 
display it

Note: after I exit and restart, the collapsed header area comes up so the info 
is not saved.
Keywords: beta2
*** Bug 35698 has been marked as a duplicate of this bug. ***
*** Bug 36140 has been marked as a duplicate of this bug. ***
*** Bug 36237 has been marked as a duplicate of this bug. ***
changing severity to normal to ensure this gets noticed, I agree it's not a 
blocker (as originally marked) though I don't believe it's just minor.
Severity: minor → normal
Yes, it's not a blocker, but the problem is that there is no way to uncollapse 
that's apparent to the user.
*** Bug 36256 has been marked as a duplicate of this bug. ***
suggest adding " - tab disapear vanish lost" to end of summary to avoid future 
dupes. Current summary garunteed not to match obvious query attempts. (At 
least, my three before I submited didn't turn up anything).
*** Bug 36275 has been marked as a duplicate of this bug. ***
*** Bug 36294 has been marked as a duplicate of this bug. ***
*** Bug 36346 has been marked as a duplicate of this bug. ***
Keywords: nsbeta2
*** Bug 36457 has been marked as a duplicate of this bug. ***
*** Bug 36474 has been marked as a duplicate of this bug. ***
*** Bug 36536 has been marked as a duplicate of this bug. ***
There's been a lot of complaints as to the summary of this not showing up in 
queries, thus producing dupes...the summary's got grippie, collapse, toolbars 
and hide though....I can't think of a better way to phrase it, can anyone else?
Keywords: beta2
look at my comment a few up. add that string to the end. i searched for those
terms before i reported a duplicate a few days ago.
cc'ing me
related to bug 21341? "UI: Remember toolbar expand/collapse state"
*** Bug 36670 has been marked as a duplicate of this bug. ***
Modifying summary from "Using grippie to collapse toolbars completely hides 
them" to get a few more matches when people search for duplicates.

Note for dark@c2i.net : No, 21341 (and kin) deal with persisting state
between runs of the browser/mail/etc. 
Summary: Using grippie to collapse toolbars completely hides them → Using grippy to collapse toolbars completely hides them (disappear vanish)
*** Bug 36702 has been marked as a duplicate of this bug. ***
This behaviour is determined by  

    box > *[collapsed="true"] {
      visibility: collapse;
    }
in global.css. Is this correct? Shouldn't the base behaviour of 
a toolbar be excepted from this rule, more like:

    box > toolbar[collapsed="true"] {
      visibility: collapse;
    }

Marking dogfood: this is core functionality IMHO, and it affects mailnews
as well as browser.
Keywords: dogfood
Umm, I meant 'visibility: visible;' in the second instance above. Really.
Putting on [dogfood+] radar
Whiteboard: [dogfood+]
being the curious little guy i am, and knowing very little of css and 
programming, i decided to try out jrgm's changes, and apparantly they work for 
me. With both toolbar and *, as long as there is visibility:visible;

here's what i did to global.css in my M15 Win32 build, (2000041805)

box > *[collapsed="true"] {
  visibility: visible;
}

however it also worked with toolbar instead of *
*** Bug 36824 has been marked as a duplicate of this bug. ***
*** Bug 36824 has been marked as a duplicate of this bug. ***
This is dependent on bug 36883, since we can't even press the grippies without 
fixing that first.
Depends on: 36883
Another workaround (at least for me) is to quit and restart mozilla. You get the
minimised grippy things that you can then click on to open the toolbars back up
yeah, that's the same idea that jrgm said earlier:
"(By the way, a workaround (to recover the grippies) is 'File->New Navigator 
Window' -- this will show the toolbar grippies on the new window in the closed 
state. You can then open the toolbars to show the icons and menus, etc.)"
This affects IM as well. CC scalkins and amusil
*** Bug 37224 has been marked as a duplicate of this bug. ***
I'm having trouble seeing how this blocks 31485 and 36361 (?)
Ben,
What is the status of this dogfood bug? On 4/21 there was a proposal for a fix, 
but I've seen no comment.  
Please put a fix-date into the status whiteboard showing that you've looked 
at this, and are working on a solution.  Dogfood is meant to take a high 
priority in order to un-block others, including users.

If you want to assert this should not be dogfood, please explain the workaround 
that you'd advocate, or indicate why the report is confused and less critical 
than it might have appeared.

Thanks,
Jim
It doesn't block bug 31485, but it does prevent its workaround.
*** Bug 37706 has been marked as a duplicate of this bug. ***
this now seems FIXED, since the toolbars no longer hide, though there's now the 
problem of bug 37766
This looks fixed to me on Linux build 20000050111 (with the noted problem of bug
37766)
*** Bug 37819 has been marked as a duplicate of this bug. ***
modulo bug #37766, as noted above, this bugs is fixed with the new UI that
ben landed in recent days (tested mac, win32, linux 20000502 a.m. builds).
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified fixed
Status: RESOLVED → VERIFIED
*** Bug 38070 has been marked as a duplicate of this bug. ***
ugh.

now appears to have returned in 2000050408 (win98), even worse than before -- 
you can, as far as I can tell, no longer get the toolbars back.  Even shutting 
down and reopening doesn't return them, there's just white emptiness in their 
space (and clicking on the space usually causes a crash).
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
taskbar is now affected by this as well (wasn't last time)
raising severity on this for now, with the added problem of the broken menus 
(just resolved as FIXED), I have nearly no way to manually go to a link now 
that I've hid the navigational bar except by redownloading/reinstalling.  In 
fact, the only way I find I can open a link is Alt+F, L (to click Open Web 
Location...), type in URL, press enter.  I'd say that's a major loss of 
function as well as quite an inconvenience. 

Should be able to bump this back down to normal once the menu fix takes effect, 
however (not yet appearing in latest nightly).
Severity: normal → major
A workaround to recover the toolbar is to open the file localstore.rdf 
in your profile and nuke a set of lines that looks like: 

<RDF:Description            
about="chrome://navigator/content/navigator.xul#PersonalToolbar">
    <collapsed>true</collapsed>
</RDF:Description>

or 

<RDF:Description about="chrome://navigator/content/navigator.xul#nav-bar">
  <collapsed>true</collapsed>
</RDF:Description>

Alternatively, just delete localstore.rdf (but this will nuke *all* your
persisted information -- sidebar states, toolbar states, window positions, etc.)
lowering severity back to normal.  menus are working again and all 
functionality is restored
Severity: major → normal
Suggest putting a relnote for M16 if this likely won't be fixed til M17.

Current note in M15 reads:

If you collapse the personal toolbars at the top of the browser window, the
toolbar will be completely hidden -- no grippy remains for you to expand the
toolbar. Workaround: Open a new browser window or restart the browser to recover
the grippy. (bug 35181)

In light of the fact that the recommended workaround there no longer works, I
suggest replacing it with the one john mentioned - about localstore.rdf - in M16
release notes if this doesn't make it by then.
Keywords: relnote
Eeek. Advising _all_ users to edit localstore.rdf (or even to delete the file)
is a pretty scary concept :-]  However, this is [dogfood+], so it should be 
fixed well before M17 ...
I figured as much.  Why don't we target this for M16, then?
BTW, for John's workaround, you mean that it should be <collapsed>false<
/collapsed>, right?  That works for me...
Yes, false is fine, although just deleting the line (or the three line "branch")
also works. 

To answer the other suggestion, I think ben will fix this shortly, but he has a 
number of things on his plate. (i.e., dogfood+ trumps M17)
*** Bug 38420 has been marked as a duplicate of this bug. ***
*** Bug 38420 has been marked as a duplicate of this bug. ***
*** Bug 38449 has been marked as a duplicate of this bug. ***
*** Bug 38718 has been marked as a duplicate of this bug. ***
*** Bug 38718 has been marked as a duplicate of this bug. ***
Keywords: 4xp
Blocks: 37954
*** Bug 38845 has been marked as a duplicate of this bug. ***
Blocks: 37766
Now appears to be fixed again in 2000051108 win98, with the noted problem of 
bug 37766 still occurring. wfm or FIXED?
2000-05-11 LINUX also working save bug 37766. sidebar is still funky (whats it
been, since M14 that it woked?) but im sure theres a seperate bug (plus 50
dupes) filed for that.
Yep, the toolbars work correctly w.r.t. collapsing (modulo bug #37766)
mac/linux/win32 20000511a.m. comm. builds. Marking FIXED and bidding
a fond farewell to 28 duplicates and 4 dependent bugs :-]
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
vrfy
Status: RESOLVED → VERIFIED
Let us not be so fond in our farewell.

Remember when I said this on 5/1:

"this now seems FIXED, since the toolbars no longer hide, though there's now the
problem of bug 37766"

and then it regressed? :)

::prays to god this is gone forever::
*** Bug 39240 has been marked as a duplicate of this bug. ***
been instructed to add mostfreq to this (sorry for spam)...
Keywords: mostfreq
*** Bug 40384 has been marked as a duplicate of this bug. ***
*** Bug 40829 has been marked as a duplicate of this bug. ***
*** Bug 40975 has been marked as a duplicate of this bug. ***
*** Bug 41401 has been marked as a duplicate of this bug. ***
*** Bug 42146 has been marked as a duplicate of this bug. ***
*** Bug 42638 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.