142661 - RC2 (2002050516) won't shutdown

Status: RESOLVED DUPLICATE of bug 144027

(SeaMonkey :: General, defect)

Description

[Keith E. Moe]

Comment 1

[Keith E. Moe]

Clicking on the quickvote on www.cnn.com does nothing.  It  works on 0.99.  This
is on 2002050516.

Also, clicking Help/About Mozilla doesn't work.  The about: URL does.

The Browser also won't shut down.  I have to C-A-D to recover.

Sorry about putting multiple problems in one ticket, but it seems that  Bugzilla
is throwing away half my bug reports and I want to maximize my chances of
getting them known.

Comment 2

[Keith E. Moe]

Sorry about the second report.  The first one never showed up, so I reported it
again.  But there is the shutdown problem....

Comment 3

[Mike Kaply [:mkaply]]

I don't understand. When you select File->Close, it doesn't close?

Comment 4

[Keith E. Moe]

I should clarify the shutdown description.  I close the browser and it closes
the window and the HD runs for a while, like its free memery and cache (normal
behavior).  But the icon never uncrosshatches and it cannot be restarted.  It
becomes a zombie which requires a C-A-D to fix.  Even normal desktop shutdown
won't complete.

I'm running this on a Warp 4, FixPak 5 system.

Comment 5

[Keith E. Moe]

This is related to the CNN quickvote problem.  If I do anything that  attempts
to create a new window: Help/About, New Navigator Window, Manage Bookmarks,
etc., the window list shows the original navigator window and a blank line
(numbered) for each window attempted to be created.

If I do nothing to create a secondary window, the browser shuts down fine.

Comment 6

[Mike Kaply [:mkaply]]

I need to know if this started in the May 3 build

Do you by chance have a May 2 and May 3 build?

Comment 7

[Keith E. Moe]

No.  I had use the 04/30 build, then the 05/05 and now the 05/06.

However, I do believe that it might have occurred in the 04/30 or the 04/26
builds, as I had the problem shutting down last Friday evenin as I left work and
I don't believe I was using the 05/02 build.  Unofrtunately, I only keep the
last two builds around on my work machine, as I have limited freespace.

Comment 8

[Keith E. Moe]

This original report was for my work system (fix pak 5).  My home system which
is running MCP1 encounters the exact same problem with the attempt to create any
new window.

This problem does not occur with 0.99 or RC1.

The only desktop enhancer I have is Taskbar, which doesn't get involved in most
desktop actions.  It provides better functionality that the Windows 95 Taskbar
and was doing it two years before Windows 95 existed.

Unofortunately, although I have plenty of disk space at home, I was keeing every
build level I downloaded there, either, so I cannot tell exactly when this
started happenning.

Comment 9

[Mike Kaply [:mkaply]]

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

Comment 10

[Mike Kaply [:mkaply]]

I wonder if this is related to the new XUL fast load code. Does it happen the 
same if you create a new profile?

Could you also try deleting chrome.rdf in the bin/chrome directory and then 
restarting?

Comment 11

[Keith E. Moe]

If I create a brand new profile, the problem goes away, so you are on the right
track.

I will be trying the chrome deletion shortly and will post the results of that
as well.

Comment 12

[Keith E. Moe]

Deleting the chrome.rdf file made no difference.  It created zombie tasks when
attempting to create additional windows.

So what might be in my profile that triggers the problem.  Since I have it on
two different machines (home and work), it's not caused by something unique to
my profiles.

Comment 13

[Mike Kaply [:mkaply]]

OK, let's start with files in the profile.

With the new profile that works, can you try copying files over one at a time 
until we find the one that causes the failure?

Comment 14

[Keith E. Moe]

I went through every member of the profile one at a time stopping mozilla,
copying one member, starting it, and selecting help/about.  (Can you imaging how
long this takes on a P-100 with 64Meg?)  It worked every time.

Then I copied the chrome.rdf file from the chrome subdirectory  in the old
profile to the new profile's chrome subdirectoty.  

Bingo! It hangs on any secondary window.  Now the old chrome directory had a
bunch of downloaded skins (for 0.99 and/or RC1), but the ACTIVE skin was
classic.  Now I understand the warning about incompatible skins causing
problems, but since none of them were active, why should it impact secondary
windows (and not the primary window)?

Since this information is being kept in the profile and is also supplied
(initially) in the mozilla/bin/chrone directory, how can this information be
migrated to the profile from the bin/chrome directory when a different
build/release is being used that is incompatible?

And even if it's incompatible, it should be ignored, not cause a hang.

Comment 15

[Mike Kaply [:mkaply]]

Can you post the bad chrome.rdf? I'll take a look.

Comment 16

[Keith E. Moe]

Attachment: Contents of profile chrome directory

Only the chrome.rdf file had to be copied to my new profile chrome directory to
experience the problem, but I wanted you to see everything I had.

Comment 17

[Keith E. Moe]

Note on the above attachment:  I tired to attach a zipped copy of my entire
profile chrome directory (a bunch of jar and css files), but it didn't seem to
work, so all I attached was the plain text chrome.rdf file.  Copying it alone to
by test profile chrome directory was enough to cause the problem.

Comment 18

[Michael Spertus]

This bug should be confirmed. I am experiencing exactly the same problems (with 
RC2 on Win XP): Shutdown doesn't work. Help/About doesn't work. Quickvote 
doesn't work. I'm going to try cleaning up the chromes. I also think this 
should be upgraded to critical or blocker, because it is a disaster.

Comment 19

[Matthias Versen [:Matti]]

*** This bug has been marked as a duplicate of 144027 ***