245037 - The Category window in the Edit Preferences dialog is empty.

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[William J. Adams]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514 MultiZilla/1.6.3.1d
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514 MultiZilla/1.6.3.1d

Using 1.7 RC2 on a Dell Dimension 4600 running Windows XP.  When I choose Edit
Preferences, the Catafory Tree is empty and therefore I can not access most
preferences.  Further, once I have opened and closed this dialog once, I can not
access it again at all.  That is, if I select Edit Preferences a second time in
the same session, nothing at all happens.

Reproducible: Always
Steps to Reproduce:
1.Start Mozilla 1.7 RC2
2.Select Edit
3.Select Preferences

Actual Results:  
On the first try, the Preferences dialog box appears, but the Catagory tree
window on the left side of the box is empty.  On subsequent trys in the same
session, no dialog box appears at all.  Nothing happens when Edit Preferences is
selected.

Expected Results:  
The Catagory tree should have been visible.  And I should be able to access the
dialog box as many times as needed in the same session.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this a problem without Multizilla?

Comment 2

[William J. Adams]

Further to my initial report:
I created a new profile without Multizilla and reproduced the same situation. 
So it appears that Multizilla is not an issue here.

Also, I have noted that, if I try to open the Edit Preferences a second time in
the same session, not only do I not get the Dialog box, but after the second
attempt the Mozilla.exe process does end properly when the browser is closed. 
That is, an alt/cntl/del will show Mozilla.exe as a running process, even after
the browser is closed, if I have tried and failed to open the Edit Preferences
Dialog a second time in the same session.

Comment 3

[William J. Adams]

This bug clears in RC3 for me.  The edit preferences catagory tree seems to
display fine, including the Multizilla options.

Comment 4

[Markus Albe]

Happens the same thing to me running Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.7) Gecko/20040616... I think it has something to do with a Firefox
0.9 install I did... could that be possible?

Comment 5

[William J. Adams]

(In reply to comment #4)
> Happens the same thing to me running Mozilla/5.0 (Windows; U; Windows NT 5.1;
> en-US; rv:1.7) Gecko/20040616... I think it has something to do with a Firefox
> 0.9 install I did... could that be possible?

For me, the bug cleared with 1.7 RC3, and with the final 1.7.  I am also running
Firefox 0.9 along with Mozilla 1.7 and it does not seem to cause the problem to
recur for me.

Comment 6

[Xavier Degeneve]

Hi, 
 
I migrate an existing account from a PC to another (Mozilla 1.7) with patch 
for fixing the :shell exploit. Same OS: WindowsXP. 
 
I have exactly the smae issue on my new PC: 
- Preference is empty 
- Next call to preference is ignored 
- When closing mozilla a mozilla process continue to run. 
 
My migration work well, both mail and http proxy are ok. I just copy all the 
AppData\Microsoft\Users\* files to overwrite the new default account and it 
works ... but could not access pref. Note that all pref could be seen in 
about:config page, (no path are bad :-)). 
 
Thanks, Xavier 

Comment 7

[Tim Tendler]

Attachment: Screenshot

I have exactly the same problem with Mozilla 1.7.2

Comment 8

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 9

[Bill Weinman]

I have been having this exact same problem for a long time (months) starting
with the installation of 1.7.x or so. I just installed 1.7.12 in the hopes that
it was cleared up, but I still have the same problem. 

Comment 10

[Andrew Schultz]

Can you try a clean profile?  Also try a more recent build:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/latest-mozilla1.8/

Comment 11

[Kevin]

seeing same problem, had 1.7.8 installed, changed to 1.7.12 and problem stayed, seeing all the same details, including hang of the preferences window if I attempt to reopen it, the window menu lists a blank window, and mozilla remains in processes list on closing, restarting mozilla without terminating the process first gets a window up quick with no splash screen.

Comment 12

[Eric Zurcher]

I'm seeing this behaviour in Mozilla 1.7.12. I'm not entirely certain, but I think the problem began for me after I installed a beta copy of SeaMonkey. I suspect something got corrupted in the profile. No problems if I work under a newly created profile.

Comment 13

[Eric Zurcher]

My previous post was misleading. Seamonkey was not the trigger for the problem. 

Eventually I did track down the cause (for my case only - mileage may vary). Within the file ...\chrome\communicator\contents\overlays.rdf, nested within the element for 
<RDF:Seq RDF:about="chrome://communicator/content/pref/preftree.xul">, there was a line reading <RDF:li>chrome://imagezoom/content/options_mozOverlay.xul</RDF:li>. Removing this line solved the problem.

What appears to have happened is that I had installed an early version of the ImageZoom addon, which used the above line to insert its own category in the Edit\Preferences dialog. I later updated to a newer version of ImageZoom, which apparently uses a different name for the overlay (prefOverlay_mozilla.xul). The old name was still in the RDF, but was now pointing to something that no longer existed.

This may just be a configuration issue, but perhaps it is a "bug" in the sense that Mozilla should be able to recover from the situation more gracefully.

Comment 14

[Arun Prasannan (polar)]

1.7.x is out of date and unmaintained. Could you try a recent version of SeaMonkey (http://www.seamonkey-project.org/releases/) please?