Closed Bug 60340 Opened 24 years ago Closed 24 years ago

Browser hangs system doing resize

Categories

(Core :: XUL, defect, P4)

Product:
Core
Component:
XUL
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ccurtis0, Assigned: danm.moz)

Details

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.
->danm
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
Closed: 24 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.