I installed an older version of Mozilla some time ago (an M18 based nightly, iirc) on a Windows NT 4.0 system with service pack 6a installed. It worked until I tried to resize the window, then the system hung. The mouse cursor displayed the 'resize' arrow, and would move, but nothing else would work, including ctrl-alt-delete - the machine had to be hard restarted. I suspected it was a known issue and dropped it. Yesterday a coworker tried installing Netscape 6 and had the exact same problem. Although it was a different machine, it was also running SP6a. Evidently the problem was not known/fixed. So I downloaded a nightly this afternoon and installed it. I could do some searching, and some resizing, but after closing a window, I got the resize cursor (l-r) and the system is now again hung. Ctrl-Alt-Delete does nothing, and the machine will have to be powered down. I suspect that when I closed the top window, the cursor appeared over an edge (possibly the inside edge, between the browser pand and the sidebar pane) and re-exercised the resize bug. I could not find any reference to this problem in bugzilla, but didn't check the Netscape DB.
coudl you get a talkback build and report an incident?
I'm afraid not; when it hangs, it hangs solidly. Moving the mouse around and clicking the buttons randomly will eventually make NT 'click', like the message buffer was full, but only once - it doesn't click again. I'm not sure if this means that the buffer is emptying or if it's locking up tighter. These are talkback-enabled products. One correction is that the machines are not the same - one is ServicePack 5, but I think the other is still ServicePack 6a. I had a report that the same thing happened on a (troublesome) Win95 machine after leaving it [Netscape6] open overnight, but I can't say what the cause of that was.
Assignee: asa → trudelle
Component: Browser-General → XP Toolkit/Widgets
QA Contact: doronr → jrgm
Unable to reproduce with build 111604 (or any recent builds) on NT4 sp5. Changing component.
It seems that the longer the system is up, the easier it is to reproduce; it may have nothing to do with resizing at all. Perhaps it has to do with layout in general that resizing tickles. Using build 2000111604 w/talkback I started mozilla, which goes to our intranet page (very simple layout). I then double clicked the location bar and typed "www.mozilla.org". Under "Nightly Builds" I selected "etc" and got most of the directory. There seems to be a reflow as soon as the download is complete, but instead of doing that, it locked. I moved the mouse and clicked randomly until NT cried BEEP!, at which point the mouse no longer moved. I powered the machine off, let it rest, logged back in as Administrator, and tried it again: no problems. I resized the browser several dozen times, went to google.com and searched for green brains and resized the window. Opened each link in a new window and rezied and closed them on top of each other, trying to get the close to end up with a resize arrow. One of the pages took me to ananova.com, which I tried to view by clicking on the green haired announcer. A window poped up saying 'click here to download plugin' which did nothing. After the seventh try or so, I did a view source, then went to google to search for RTSP. I went to the RTSP FAQ, which sent me off to www.prognet.com - where the browser locked (text entry cursor) before it finished rendering the page. I tried to hit ctrl-alt-delete, moved the mouse, and clicked randomly until nt cried BEEP! The hard drive chugged a little, but the system is otherwise completely unresponsive - mouse, keyboard lights, 3 finger salute.
Have you, or anyone else, been able to reproduce any of these incidents? They seem like random crashes to me, especially since the liklihood increases with runtime. We need reproducible steps in order to act on this bug.
I've tried to turn off the entropy generator but haven't had much success finding it in the registry ... I'm using one of the later nightlies right now on a different NT machine and am not having any problems. I just ran Mozilla build 2000121204 on one of the problem machines and it again locked while I was browsing x.themes.org. Here's something interesting though: All the machines that have the Windows version of the GIMP installed (http://www.gimp.org/win32/) exhibit this problem. The one that does not have this problem does not have the GIMP installed. Could there be some kind of odd GTK interaction going on here? (Lowering priority since this doesn't seem widespread)
Priority: P3 → P4
Is GIMP running, or resident in any way, at the time of the crash? (BTW, the assignee/module owner also owns the priority field, please don't change it)
Nope, not running. Nothing is running but Mozilla and whatever starts up with NT. The synopsis is that I have 4 Windows machines, three NT, one 95. Two NT machines have the GIMP, as does the 95 machine. On all of these Mozilla is problematic. The remaining NT machine has a bunch of CygWin stuff, but no GIMP, and runs Mozilla flawlessly. I can't think of any other installed software that is this easily partitioned. re: the Priority field, if it really is 'owned' by the 'assigned to', this should be enforced by bugzilla. I believe I can set the priority when I first file the report. Not trying to stir anything up - I'm not going to override someone else's setting - but this should be enforced in software.
I've installed the Gimp on my win2k system, so I'll see if anything comes up for me. (Since 'dS/T > 0', we'll see if something happens eventually).
Thanks John. I'll leave the bug open pending steps to repro. Re: priority field, that is a policy set by mozilla.org, defined in the Priority link above, not something that is enforced by bugzilla itself, although it would be nice. However, nobody can set priority when reporting a new bug via the standard bugzilla form.
Assignee: trudelle → danm
Christopher Curtis, this sounds a lot like a profile corruption. Are you sharing your profile between the 4 machines? Are you migrating the ns4 profile? I would recommend using a fresh profile (i.e. not one created by ns4 or ns6). Sorry if you already tried this, then ignore. Thanks, Fabian.
Each time I've installed it on a new machine I've created a new profile. I found another machine with the Gimp, and I just asked that person to test it for me. I'll see what happens in a couple days. ps - It's a very bad thing for profile corruption to hang an entire machine.
By the way, I did run with the Gimp/win32 concurrent with Mozilla for a couple of days, and had no problems noted. Yes, it is very bad for a corrupt profile to hang a machine. If we can identify exactly how to reproduce this, then we do want to prevent this from occurring.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I haven't done too much more with this, but I just tried the latest nightly from Mozillazine (1/24) and it seems to be more stable. I run a bunch of the ZDNet Browser compatibility tests from the Browser Buster under Debug (failure rate was higher that I expected; the XML tests wouldn't even try to run) with no lockups. The scrollbar wouldn't move a couple times and the first time it happened, I paniced (ctrl-alt-delete) but it turns out the scrollbar was just unresponsive. Trying again freed it. So far, so good, but I'm leaving it open since another machine just locked up with mozilla open overnight. One additional thing: My personal machine also has the Gimp and Mozilla installed and I've never had a lockup. This does not completely eliminate it yet, though, because on my machine, the Gimp was installed after Mozilla; on the others, it was installed before.
resolving as wfm
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.