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.
Sorry about the second report. The first one never showed up, so I reported it again. But there is the shutdown problem....
Severity: normal → major
Summary: QuickVote on CNN doesn't work. → RC2 (2002050516) won't shutdown
I don't understand. When you select File->Close, it doesn't close?
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.
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.
I need to know if this started in the May 3 build Do you by chance have a May 2 and May 3 build?
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.
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.
*** Bug 142657 has been marked as a duplicate of this bug. ***
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?
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.
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.
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?
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.
Can you post the bad chrome.rdf? I'll take a look.
Created attachment 82937 [details] 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.
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.
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.
*** This bug has been marked as a duplicate of 144027 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.