133733 - Browser locks up xwindows during download of page

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Martin Pagnan]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204

The browser will lock up xwindows so that bringing down xwindows is
necessary to get out of the problem. It seems to occur when the 
sending site is simultaneously upgrading their site. It therefore has
repeatedly occured with sites like Drudgereport and mind. However, there
are other sites. At first I thought that it might be a local configuration
problem but that does not seem likely. It happens about once per day on my
Linux box. It does not occur on my windows box running the latest release of
mozilla for Windows.

Comment 1

[Olav Vitters]

Reporter: Can you reproduce this with a nightly build, available at:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu.tar.gz

What version of X are you running?

If it is a 4.x version, can you add the following to your XF86Config-4 in the
'Section "ServerFlags"' (and restart the X server):
  Option "AllowDeactivateGrabs" "1"

When X locks up, press Ctrl+Alt+Keypad-Divide. Does X work after that?

Comment 2

[Martin Pagnan]

The version of x that I am running is 4.3. I have now set "AllowDeactivateGrabs" 
to "1". It seems to have no effect. X reboots as before with <ctrl><alt>-.

The bug is difficult to reproduce. I believe that I have to be online while
the connected URL is simultaneously trying to upgrade their page. This happens
fairly often with news sites but I could not make it happen today. I will try
a later version tomorrow.

Comment 3

[Martin Pagnan]

I have not been able to get this bug to appear as described for two
days. However, I have found similar behaviour when I try to print
while a page from any URL is downloading (at 56K - there is no problem
at higher speeds. Here is a way to reduplicate the problem that seems
to fail every time. Connect to this at 56K
http://heather.cs.ucdavis.edu/itaa.real.html
It takes about 2 minutes to download with a good connection. While it is 
downloading, hit <file><save page as><enter>. This will lock up Mozilla
tight as a drum every time. This is not the same cause of the lock up as
reported earlier but it is related. Earlier I reported that the lockup
occured while a URL was downloading and I tried to do something else. So,
maybe they are related. 

Comment 4

[John Levon]

Did you make sure to uninstall all previous versions of Mozilla ?
Does a new profile help ?

For me, the save dialog does not arrive until loading is complete.

Comment 5

[Martin Pagnan]

Yes. All previous versions have been uninstalled. I am beginning to 
think that the problem relates to the sequences in Mozilla programming: If
I use Opera, each web item (text, graphic, etc.) appears as it is received.
However, if I go to the same web pages with Mozilla, nothing appears until
after large pieces of the page have been loaded, I guess, into a buffer.
During the time that this buffer is being loaded, Mozilla is not usable.
That is, the stop and reload buttons are grayed out. If the transmission
stops while the buffer is being filled, I experience a lockup. To get around
it I just kill the Mozilla process and restart.

Comment 6

[Kai Lahmann (is there, where MNG is)]

WFM with trunk 2002073022, linux. reporter (Martin Pagnan): can you reproduce
this bug with a recent build of mozilla (for example, 1.1beta)? if so, please
comment again with details. if not, please resolve this bug as WORKSFORME. thanks.

Comment 7

[Kai Lahmann (is there, where MNG is)]

no answer.