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)
Core
XUL
Tracking
()
VERIFIED
FIXED
M17
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.
Reporter | ||
Comment 1•24 years ago
|
||
changing component to more appropriate XP Toolkit/Widgets, as problem deals specifically with toolbars.
Component: Browser-General → XP Toolkit/Widgets
Updated•24 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•24 years ago
|
||
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)
Reporter | ||
Comment 3•24 years ago
|
||
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
Comment 4•24 years ago
|
||
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
Comment 6•24 years ago
|
||
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
Reporter | ||
Comment 8•24 years ago
|
||
added regression kw which should have been there earlier
Keywords: regression
Comment 10•24 years ago
|
||
This bug breaks the workaround for bug 32120.
Comment 11•24 years ago
|
||
*** Bug 35370 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
*** Bug 35698 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
*** Bug 36140 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
*** Bug 36237 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 16•24 years ago
|
||
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
Comment 17•24 years ago
|
||
Yes, it's not a blocker, but the problem is that there is no way to uncollapse that's apparent to the user.
Comment 18•24 years ago
|
||
*** Bug 36256 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
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).
Comment 20•24 years ago
|
||
*** Bug 36275 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 21•24 years ago
|
||
*** Bug 36294 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
*** Bug 36346 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
*** Bug 36457 has been marked as a duplicate of this bug. ***
Comment 24•24 years ago
|
||
*** Bug 36474 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 25•24 years ago
|
||
*** Bug 36536 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 26•24 years ago
|
||
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
Comment 27•24 years ago
|
||
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.
Comment 28•24 years ago
|
||
cc'ing me
Comment 29•24 years ago
|
||
related to bug 21341? "UI: Remember toolbar expand/collapse state"
Reporter | ||
Comment 30•24 years ago
|
||
*** Bug 36670 has been marked as a duplicate of this bug. ***
Comment 31•24 years ago
|
||
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)
Comment 32•24 years ago
|
||
*** Bug 36702 has been marked as a duplicate of this bug. ***
Comment 33•24 years ago
|
||
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
Comment 34•24 years ago
|
||
Umm, I meant 'visibility: visible;' in the second instance above. Really.
Comment 36•24 years ago
|
||
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 *
Comment 37•24 years ago
|
||
*** Bug 36824 has been marked as a duplicate of this bug. ***
Comment 38•24 years ago
|
||
*** Bug 36824 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 39•24 years ago
|
||
This is dependent on bug 36883, since we can't even press the grippies without fixing that first.
Depends on: 36883
Comment 40•24 years ago
|
||
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
Reporter | ||
Comment 41•24 years ago
|
||
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.)"
Comment 42•24 years ago
|
||
This affects IM as well. CC scalkins and amusil
Reporter | ||
Comment 43•24 years ago
|
||
*** Bug 37224 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Reporter | ||
Comment 44•24 years ago
|
||
I'm having trouble seeing how this blocks 31485 and 36361 (?)
Comment 45•24 years ago
|
||
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
Comment 46•24 years ago
|
||
It doesn't block bug 31485, but it does prevent its workaround.
Comment 47•24 years ago
|
||
*** Bug 37706 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 48•24 years ago
|
||
this now seems FIXED, since the toolbars no longer hide, though there's now the problem of bug 37766
Comment 49•24 years ago
|
||
This looks fixed to me on Linux build 20000050111 (with the noted problem of bug 37766)
Comment 50•24 years ago
|
||
*** Bug 37819 has been marked as a duplicate of this bug. ***
Comment 51•24 years ago
|
||
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
Reporter | ||
Comment 53•24 years ago
|
||
*** Bug 38070 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 54•24 years ago
|
||
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 → ---
Reporter | ||
Comment 55•24 years ago
|
||
taskbar is now affected by this as well (wasn't last time)
Reporter | ||
Comment 56•24 years ago
|
||
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
Comment 57•24 years ago
|
||
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.)
Reporter | ||
Comment 58•24 years ago
|
||
lowering severity back to normal. menus are working again and all functionality is restored
Severity: major → normal
Reporter | ||
Comment 59•24 years ago
|
||
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
Comment 60•24 years ago
|
||
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 ...
Reporter | ||
Comment 61•24 years ago
|
||
I figured as much. Why don't we target this for M16, then?
Comment 62•24 years ago
|
||
BTW, for John's workaround, you mean that it should be <collapsed>false< /collapsed>, right? That works for me...
Comment 63•24 years ago
|
||
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)
Comment 64•24 years ago
|
||
*** Bug 38420 has been marked as a duplicate of this bug. ***
Comment 65•24 years ago
|
||
*** Bug 38420 has been marked as a duplicate of this bug. ***
Comment 66•24 years ago
|
||
*** Bug 38449 has been marked as a duplicate of this bug. ***
Comment 67•24 years ago
|
||
*** Bug 38718 has been marked as a duplicate of this bug. ***
Comment 68•24 years ago
|
||
*** Bug 38718 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 69•24 years ago
|
||
*** Bug 38845 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 70•24 years ago
|
||
Now appears to be fixed again in 2000051108 win98, with the noted problem of bug 37766 still occurring. wfm or FIXED?
Comment 71•24 years ago
|
||
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.
Comment 72•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 74•24 years ago
|
||
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::
Comment 75•24 years ago
|
||
*** Bug 39240 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 76•24 years ago
|
||
been instructed to add mostfreq to this (sorry for spam)...
Keywords: mostfreq
Comment 77•24 years ago
|
||
*** Bug 40384 has been marked as a duplicate of this bug. ***
Comment 78•24 years ago
|
||
*** Bug 40829 has been marked as a duplicate of this bug. ***
Comment 79•24 years ago
|
||
*** Bug 40975 has been marked as a duplicate of this bug. ***
Comment 80•24 years ago
|
||
*** Bug 41401 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 81•24 years ago
|
||
*** Bug 42146 has been marked as a duplicate of this bug. ***
Comment 82•24 years ago
|
||
*** 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.
Description
•