73064 - If Navigation Toolbar disappears, un/rechecking it in View->Toolbars does nothing

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[michael_bourgon]

(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)

Comment 1

[Asa Dotzler [:asa]]

[e-mail], 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.

Comment 2

[michael_bourgon]

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.  

Comment 3

[michael_bourgon]

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.  

Comment 4

[Asa Dotzler [:asa]]

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.

Comment 5

[Keyser Sose]

This WORKSFORME marking as such.

Comment 6

[michael_bourgon]

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.

Comment 7

[michael_bourgon]

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.

Comment 8

[doctor__j]

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.

Comment 9

[Diego Biurrun]

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.

Comment 10

[James Barwick]

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. 

Comment 11

[rob cherny]

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 ... 

Comment 12

[doctor__j]

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

Comment 13

[Asa Dotzler [:asa]]

Modern only.  over to hewitt.

Comment 14

[Diego Biurrun]

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

Comment 15

[Diego Biurrun]

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

Comment 16

[lchiang]

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

Comment 17

[Blake Ross]

taking.

Comment 18

[Blake Ross]

Attachment: fix

Comment 19

[Blake Ross]

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

Comment 20

[Blake Ross]

r=kerz sr=ben for 0.9.2.

Comment 21

[tor]

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

Comment 22

[Asa Dotzler [:asa]]

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)

Comment 23

[Blake Ross]

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

Back to hewitt.

Comment 24

[Marek Z. Jeziorek]

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.

Comment 25

[Mike Pinkerton (not reading bugmail)]

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.

Comment 26

[Blake Ross]

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

Comment 27

[jag (Peter Annema)]

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

Comment 28

[jag (Peter Annema)]

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...

Comment 29

[jag (Peter Annema)]

Attachment: [patch] Whatever works...

Comment 30

[Chris Lyon]

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

Comment 31

[jag (Peter Annema)]

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").

Comment 32

[jag (Peter Annema)]

Attachment: [patch] Whatever works, and then some...

Comment 33

[Ben Goodger (use ben at mozilla dot org for email)]

sr=[e-mail] for the branch. 

Comment 34

[jag (Peter Annema)]

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

Comment 35

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 36

[djk]

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.

Comment 37

[Michael Baffoni]

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).

Comment 38

[Chase Tingley]

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

Comment 39

[John Morrison]

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

Comment 40

[jag (Peter Annema)]

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.

Comment 41

[Chase Tingley]

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

Comment 42

[Ben Ross]

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.

Comment 43

[Peter Trudelle]

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

Comment 44

[Jaime Rodriguez, Jr.]

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

Comment 45

[R.K.Aa.]

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

Comment 46

[Jaime Rodriguez, Jr.]

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

Comment 47

[jag (Peter Annema)]

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.

Comment 48

[selmer (gone)]

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...

Comment 49

[jag (Peter Annema)]

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.

Comment 50

[Jaime Rodriguez, Jr.]

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 51

[Asa Dotzler [:asa]]

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.

Comment 52

[jag (Peter Annema)]

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

Comment 53

[jag (Peter Annema)]

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

Comment 54

[[not reading bugmail]]

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

Comment 55

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 56

[Asa Dotzler [:asa]]

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

obsoleting checked in patch.

Comment 57

[Eric Gerlach]

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

Comment 58

[jag (Peter Annema)]

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

Comment 59

[CJ Kucera]

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.

Comment 60

[CJ Kucera]

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

Comment 61

[jesse]

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.

Comment 62

[Robert Kaiser]

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

Comment 63

[Robert Kaiser]

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

Comment 64

[Robert Kaiser]

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

Comment 65

[Robert Kaiser]

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

Comment 66

[Robert Kaiser]

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

Comment 67

[michael_bourgon]

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

Comment 68

[Robert Kaiser]

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