(this may be two bugs, not sure) I've managed a couple of times to get rid of the Navigation toolbar totally. No grabby remains, and it's not on-screen. If you go to View->Toolbars it shows as checked, and if I uncheck and recheck it, nothing happens, but several minutes later the grabby reappears. Unfortunately I have no idea what I did to it, but I've done it 2 or 3 times. FWIW, I normally browse with only Personal toolbar uncollapsed, the other two (Navigation and Menu) collapsed. (this is on the .8.1 candidate 2001031604)

mbourgon@hrw.com, I am not able to reproduce this problem. I've tried surfing for a while with the file and navigation toolbars collapsed and the navbar does not seem to disappear. Are there any steps you can provide for reproducing this problem. Thanks for your help in testing Mozilla and reporting bugs.

Asa, I'm not sure how I got to that point, but everytime I now start mozilla, the navigation bar is missing (but shows as checked in View->Toolbars). I don't know if attaching my Moz files (prefs,etc) would help locate the problem, but let me know which files, and I'll do so. I am still using the build 2001031604, as I'm afraid that if I blow away Moz and unzip a new nightly, the symptoms will be gone, but the condition may still exist.

FWIW, I have the same problem on my home machine, running the same .8.1 (I believe). I have one on NT and one on 95, if you need any of the files.

mbourgon, what would be most helpful is if you could identify the steps you took to get his behavior. Next time this happens can you try to recreate your actions leading up to the problem and see if you can reproduce it. Thanks for your help.

This WORKSFORME marking as such.

I've not been able to duplicate it, but my fear is that some poor schlub is going to manage to do so, and won't be able to fix it without deleting his prefs and starting over. At the risk of spending _way_ too much of y'all's effort on it, how does Moz know to check/uncheck the various toolbars in View->Toolbars? Does it pull that from the prefs, registry.dat or something? There's got to be a reason that it's hidden, but the toolbar list sets it's not. The reason I ask is that I have one machine with that error, and despite all the mozilla reinstalls (deleting the bin directory only, and unstuffing the new zip into the same folder), it's still happening. Thanks again.

I think I found a way to reliably reproduce the problem, at least on my machine. My guess is that the first window created when Mozilla starts is not passed the same values as subsequently opened windows (which makes sense, since changes made to a window are applied to each subsequently created window). 1) Start Mozilla. 2) Create a new window. Expand all three toolbars at the top. (Nav, Menu, Personal) 3) Quit Mozilla. (I quit it by closing the new window, then the original window created when Mozilla started) 4) Start Mozilla. Note that all three toolbars are open. (Actual Behavior same as Expected Behavior - all 3 toolbars viewable and expanded) 5) Minimize all three toolbars. 6) Quit Mozilla 7) Start Mozilla. Expected behavior: three compressed toolbars. Actual Behavior: Mozilla only shows the compressed menu bar (which is not the last one compressed). Other two are not visible. 8) Create a new window. All three bars are there, but compressed. 9) Expand all toolbars 10) Quit Mozilla 11) Start Mozilla up. Expected Behavior: All three toolbars are visible and expanded. Actual Behavior: same.

Comirmed on Win32 build 2001052904. I am trying to clean up the repro steps to make it short... 1) Make sure you have Navigation toolbar expanded and displayed on browser. 2) Collapse the Nav toolbar by clicking the handle. 3) Exit Moz. 4) Start up Moz Actual Results: Nav toolbar is totally hidden, although a tick is marked on "View -> Toolbars -> Navigation Toolbar" menu. Expected results: Nav toolbar should appear collapsed. Workaround: Launch a new window (Ctrl-N). The nav toolbar in the new window would appear collapsed and could be expanded by clicking the handle.

Bug 80630 appears to be a duplicate of this bug. I suggest changing OS -> All as I can reproduce this on Linux, see bug 80630.

I have repo'd this on Build 2001060713. GNU/Linux Glibc-2.2.2....didn't know about this bug...but it happened to me. Found the "work-around" by accident.

adding cc: .... i just accidently did this with 0.9.1 ... very confusing ... i went in and deleted mozregistry.dat and all sorts of stuff trying to get them back ...

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

Modern only. over to hewitt.

Changing OS to ALL since I could reproduce it on Linux. Bug 80630 is a duplicate of this one, but it has some useful comments from Marc Loiselle which I am pasting here now: Steps to reproduce Switch to Modern theme. Collapse navigation toolbar by clicking on grippy. Switch to classic Switch back to modern Navigation toolbar does not appear at all. Switch to classic Navigation toolbar appears collapsed. cvs build of trunk on 20010512 JavaScript error: chrome://global/content/bindings/toolbar.xml#toolbox.createCollapsedGrippy() line 3: aToolbar.findNodeByAttribute is not a function

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

for consistency, the bug marked duplicate of this once was PDT+ and other markings so I'm adding that status to this bug.

taking.

hmm...ignore that 4300px change. That was just to make sure the rule was getting hit in both places ;)

r=kerz sr=ben for 0.9.2.

a=tor for 0.9.2 branch. Get it in ASAP - we're almost finished with this release.

pushing out. 0.9.2 is done. (querying for this string will get you the list of the 0.9.2 bugs I moved to 0.9.3)

I don't know of a right way to fix this. I'm not sure there is one :-/ Back to hewitt.

Joe, Ben, this is PDT+ bug. Tomorrow, on Tuesday, we'll try to build the first RTM candidate. It would be good, if this could be resolved ASAP.

jag is taking a look at this while hyatt is away. we've verified that it's modern only. classic shows the collapsed grippy just fine. Also, it only appears to be the nav toolbar. There's no problem doing this with the personal toolbar.

Yes, Nav toolbar only because that's the primary toolbar, and modern has a special binding for it.

So does this happen because we don't allow js to be executed on theme xbl bindings?

Yay! Hixie and I found out what's going on here. Simplified: <toolbox> <menubar/> <toolbar id="nav-bar"/> <toolbar id="personal-bar"/> </toolbox> The toolbox, the menubar and both toolbars have XBL bindings which give them properties and methods. When the toolbox is bound to, its constructor executes, iterates over its childnodes (menubar, toolbar, toolbar) and calls findNodeByAttribute on them. Of course, this only works if the childnodes are bound before the toolbox is. Apparently, because of the modern skin XBL binding to the nav-bar, its binding doesn't happen until after the toolbox is bound to, so when the toolbox constructor executes, it'll try to call a method that isn't there yet. The XBL spec says that children (menubar, toolbars) should be fully initialized before their parent (toolbox) is. So the code as is should probably work, but it doesn't. Hixie and I came up with a patch, where we move the code currently executed in the toolbox' constructor to the constructor(s) of the menubar and toolbars. However, I don't think there's a guarantee that the toolbox is actually bound to at that point, so I'll definitely need to talk to hyatt about this. Anyway, patch coming up that fixes things for me...

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

Hrm, so, after some discussion with Ben and Hixie, I'll slightly modify the above patch to check if the parentNode is indeed a toolbox. We have a few toolbars which aren't inside a toolbox and we don't want to create problems there. Also, this will only go in on the branch, for the trunk we need to come up with a better fix (see "talk to hyatt").

sr=ben@netscape.com for the branch.

Checked in on the branch. Let's find a better fix for the trunk. -> hyatt

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

I ran into this on win98 build 2001081208-trunk. Tried a workaround shown above, but the grippies were gone so it didn't work. Here's the workaround I found to get the toolbars back: - Edit localstore.rdf in the profile directory. - Find where each component that's messed up (component-bar, PersonalToolbar, nav-bar, and main-menubar) has the attribute "hidden" and/or "moz-collapsed". Change the values to false to re-enable the components that disappeared.

I just ran into this problem with 2001081303, and it affects both the Nav bar and the personal tool bar if you use the grippies to collapse the bars (but not the view/Show-Hide-> toolbar which works fine, but can't uncollapse the grippy-collapsed toolbars). My way of fixing this is to launch Netscape 6.1 because the grippies show up properly in 6.1 and I can uncollapse it (guess that makes it a regression...). I have the problem in both modern and classic themes (well, the grippy stayed gone after switching from modern to classic, but I didn't check to see if it disappeared while in the classic theme).

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

add nsbranch. Needed for post 0.9.4 branch -- either a real fix, or re-apply jag's stopgap to the new branch.

ISTR that initialising in the correct order is hard, so let's go with this fix (if it still works) for the 0.9.4 branch.

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

Another way to reproduce this that I've found is to select quit from the file menu when you have one windows open with toolbars collapsed, and one with them expanded. This loses both navigation and personal toolbars for me.

->jag, nsbranch+/095/regression, need to add hack from 6.1 to branch and trunk

Update the Patch Status. Check it in - PDT+.

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

Adding correctness Status Whiteboard, correct/expected behavior does not occur.

Okay, checked in on the branch. I'll probably check this in on the trunk (need to get an OK for that) and reassign it to hyatt.

Um, were there any reviews of this for the 094 branch? I see review comments for the old branch, but not for the recent checkin...

selmer: no, I thought I didn't need those given that the patch applied without problem and the related code hadn't changed. I can get post-checkin review and super review if you want.

This is already checked into the branch, removing nsbranch+ to get it off the radar for the branch. (Note: Didn't want to give it a PDT- because we did take it on the branch) - PDT

Comment on attachment 41395 [details] [diff] [review] [patch] Whatever works, and then some... a=asa (on behalf of drivers) for checkin to 0.9.5.

Work-around checked in on trunk. Back to hyatt for the real fix. Needs bottom up constructor firing.

-> 1.0 (but feel free to move it elsewhere)

this happens with Multizilla too, you cant get the nav bar back.

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

Comment on attachment 41395 [details] [diff] [review] [patch] Whatever works, and then some... obsoleting checked in patch.

This bug hasn't seen any activity in a while... does the Nav Toolbar disappear anymore? Is this a moot point?

Yeah, we need to find a better fix than the hack that was checked in.

I don't know if this is the exact same problem, but the symptoms are the same. Navigation/Tab/Personal Toolbars are all totally gone and are not retrievable. I have reduced the problem to what I think is the simplest case, and I've put it up here: http://apocalyptech.com/moztabbar/ Essentially, when a window is opened in Javascript with "menubar=no" *or* "menubar=yes" in the window.open options, these bars are not present. Setting the appropriate dom.disable_window_open_feature.* options can force specific toolbars to remain present, but the ones that are unspecified cannot be turned back on.

I neglected to mention that I'm using Mozilla 1.4 for this. Specifically: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030710 Compiled from source, here's my about:buildconfig: Build platform target i686-pc-linux-gnu Build tools Compiler Version Compiler flags gcc gcc version 3.2.2 -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -march=pentium3 -pipe -pthread -pipe g++ gcc version 3.2.2 -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long -march=pentium3 -pipe -Wno-deprecated -fshort-wchar -pthread -pipe -I/usr/X11R6/include Configure arguments --prefix=/usr/lib/mozilla --disable-pedantic --disable-short-wchar --disable-xprint --enable-mathml --without-system-nspr --enable-nspr-autoconf --with-system-zlib --enable-xsl --enable-crypto --enable-extensions=default --enable-optimize=-O2 --with-default-mozilla-five-home=/usr/lib/mozilla --enable-toolkit-gtk --enable-default-toolkit=gtk --disable-toolkit-qt --disable-toolkit-xlib --disable-toolkit-gtk2 --disable-ldap --enable-strip-libs --disable-debug --disable-tests --enable-reorder --enable-strip --enable-elf-dynstr-gc --enable-xft --disable-freetype2 --disable-svg --enable-old-abi-compat-wrappers

since I haven't figured out how to reproduce it yet, I'm not sure if this is helpful or just useless whining but... I have been having the navigation bar disappear fairly often. I have never experienced this until v1.7.2 (did not experience it with 1.7.0). Running modern theme and "home button" toolbar plugin. this is on winxp pro.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Checked on Seamonkey 1.1.15, and the problem appears to be fixed. Many thanks!

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614