bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Mozilla "freezes" when loading this page and the warning message appears too late




16 years ago
14 years ago


(Reporter: Troodon, Assigned: serge (gone))




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PL2:NA], URL)


(5 attachments)



16 years ago
The CPU use climbs to nearly 100% and Mozilla aparently freezes. But after ¡15
minutes! (it TOO MANY time, 99,9% of the users will reset the computer after
just some seconds) there's a warning message (see attachment) that lets to abort
the script and continue.
No problem with IE 5.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2a) Gecko/20020910

Comment 1

16 years ago
Created attachment 99967 [details]
Screenshot of the warning message

Comment 2

16 years ago
Reassigning to Browser-General until we can get further info.


1. Do we see the bug simply by loading the site? Or do we have
   to click a few things first. If so, please list what they are.
   The site WORKSFORME simply loading it. My CPU stays around 2%.

2. Do you get the "unresponsive script" message every time at this site?
   Or just sometimes?
Assignee: rogerl → asa
Component: JavaScript Engine → Browser-General
QA Contact: pschwartau → asa

Comment 3

16 years ago
I should have said: I'm using Mozilla trunk binary 20020911xx on WinNT -

Comment 4

16 years ago
1 - I always see the bug when I simply load that page (Mozilla "freezes" even
before rendering it).
2 - I "always" (tried only three times because the wait is too longer) get that
message after exactly 15 minutes.
Summary: Mozilla "freezes" when viewing this page and the warning message appears too late → Mozilla "freezes" when loading this page and the warning message appears too late

Comment 5

16 years ago
WFM using Mozila 1.1 build 20020826 and Win98 SE - perhaps a new profile could help?

Comment 6

16 years ago
Erik has a good idea: using a new profile will determine if
a preference setting is causing the problem. If the Mozilla 
Profile Manager doesn't come up automatically, you can force
it to by launching Mozilla from a console prompt like this:

     [(path to Mozilla)] ./mozilla -profilemanager

Once the Profile Manager comes up, click on "Create Profile".
Then try to access the site under the new profile. 

Does the problem go away?

Comment 7

16 years ago
I've tried using a new profile (no setting changed) and the problem still happens.

Comment 8

16 years ago
Troodon: thanks for trying that. I'm puzzled by this bug, though,
since this site loads so easily for me in Mozilla on my WinNT box. 

1. Are you going through a proxy server by any chance?

2. What are the CPU and RAM of your Win98 box? 

Thanks -

Comment 9

16 years ago
1- No. I've a direct DSL connection.
2- It's a K6-2 400 with 256 Mb of SDRAM.

When I have time, I'll try with a nightly build.

Comment 10

16 years ago
I tried with the build 20020924 and nothing changed.

Comment 11

16 years ago
Confirmed with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021102.
However, if I disable my Flash-plugin 6.0 r47 then the page loads fine.

Comment 12

16 years ago
Hasse: thanks. Based on that finding, reassigning from Browser-General
to Plug-ins component for further triage, and marking bug confirmed.
Assignee: asa → beppe
Component: Browser-General → Plug-ins
Ever confirmed: true
QA Contact: asa → shrir

Comment 13

16 years ago
I can confirm this one. I have it narrowed down to the following code. Accessing
the swf directly and it loads fine. If you remove the script, it loads fine. If
you remove the onload on the body, the page loads fine. If you start removing
some of the embed attributes, it loads fine. I did not make an attachment
because of the hang.

<title>Gaming in 3D | Homepage</title>
var moviename = "mainmenu";
var movie_ready = "false";
function movieobject(moviename)
  if (navigator.appName.indexOf ("Microsoft") !=-1) 
  {return window[moviename]} else {return document[moviename]}
function playmovie()
  if(movie_ready == "false")
      while(movie_ready == "false")
          if(movieobject(moviename).PercentLoaded() == 100)
              movie_ready = "true";
  else {movieobject(moviename).Play();}

<body onload="playmovie()">
<EMBED swLiveConnect=true src="http://www.gamingin3d.com/g3d_navigation.swf"
name=mainmenu loop=false menu=false quality=high wmode=opaque WIDTH=159
HEIGHT=392 TYPE="application/x-shockwave-flash"></EMBED>

Assignee: beppe → av
Keywords: hang
Priority: -- → P2
Target Milestone: --- → mozilla1.3beta

Comment 14

16 years ago
yeah, javascript call playmovie() can loop forever
if  movieobject(moviename).PercentLoaded() != 100
it looks like this is a dup of bug176782 or vice versa.
Priority: P2 → --
Target Milestone: mozilla1.3beta → ---

Comment 15

16 years ago
Ok, Serge, marking as a dup then

*** This bug has been marked as a duplicate of 17682 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 16

16 years ago
Typo in the bug number.
Resolution: DUPLICATE → ---

Comment 17

16 years ago

*** This bug has been marked as a duplicate of 176782 ***
Last Resolved: 16 years ago16 years ago
Resolution: --- → DUPLICATE

Comment 18

16 years ago
I'm reopening this bug because fix for 176782 bug does not fix this one, though
the javascript code looks similar on both url.

Resolution: DUPLICATE → ---

Comment 19

16 years ago
--> to self for further investigation.
Assignee: av → serge

Comment 20

16 years ago
Created attachment 106855 [details]
test case from comment #13

this one is WFM

Comment 22

16 years ago
Created attachment 106856 [details]
test case <EMBED> inside <TABLE> WFM w/ fix for bug176782

the only diff compare to first one is <EMBED> inside <TABLE>


16 years ago
Attachment #106855 - Attachment mime type: text/plain → text/html

Comment 23

16 years ago
ooh, yeah this is ugly, confirming
Priority: -- → P3
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.4alpha


16 years ago
Attachment #106856 - Attachment description: test case which hangs mozilla → test case <EMBED> inside <TABLE> WFM w/ fix for bug176782

Comment 24

16 years ago
Created attachment 107064 [details]
the test case with <OBJECT <EMBED>> hangs mozilla

we fall into bad loop in |onLoad| handler only when we call

Comment 25

16 years ago
Created attachment 107066 [details] [diff] [review]
patch v1.

see comments in the patch


16 years ago
Attachment #107066 - Flags: superreview?(dbaron)
Attachment #107066 - Flags: review?(peterl)
Comment on attachment 107066 [details] [diff] [review]
patch v1.

This seems like a potentially significant performance hit in some cases. 
Perhaps the right solution is something related to the DummyLayoutRequest
object in the pres shell?  Maybe the pres shell should maintain a reference
count of things that prevent onload, and the current conditions for adding /
removing the dummy layout request could increment/decrement the reference
count, and the posting and handling of CantRenderReplacedElementEvents could do
the same?  (In other words, rather than doing a flush in order to prevent
onload, just prevent onload directly.)

Does this seem reasonable?  I'm certainly not an expert on the
DummyLayoutRequest stuff, although I *think* I understand what it's there to
Er, now that I poked around a little more, the frame manager already creates a
second DummyLayoutRequest object just for this purpose.  So why isn't that code
Er, it creates one if the frame is an nsLayoutAtoms::objectFrame.  Is that true
in this case?
Attachment #107066 - Flags: superreview?(dbaron)
Attachment #107066 - Flags: superreview-
Attachment #107066 - Flags: review?(peterl)

Comment 29

16 years ago
yeah, frame manager creates DummyLayoutRequest and adds it on loadgroup
but that request is getting removed from load group in
|FrameManager::DestroyPLEvent| right after |FrameManager::HandlePLEvent| and if
there is no more |nsLoadGroup.mForegroundCount| onLoad is called, which can
happen well before new reflow events will be processed.
So is the problem that the pres shell has already destroyed its dummy layout
request and therefore won't create another one for the new reflow (which seems
like the right thing to do, since we don't want to fire onload every time an
incremental reflow happens)?  If so, perhaps the right solution is moving the
current separation of the two dummy layout requests to a refcounted system of
just managing one (and only ever creating one for the lifetime of the document,
rather than the excessive ones that seem like they might be created for object
frames now if they're added after onload and unable to render).  Such a solution
should probably apply to images too.

Comment 31

16 years ago
I was working on a refcounted solution for the dummy layout request for a
general way to delay onLoad in the patches in bug 136927 but I found that
delaying onLoad is not enough for plugins as the case when they are
document.write'ed and then accessed right away failed. 
But if they're document.written and accessed right away, we won't have handled
the CantRenderReplacedElementEvent yet either, right?  (So this patch wouldn't
make any difference that case.  Plus, the JS in this bug is basically broken
anyway, since in any case where we don't enter the |if| the first time through
the |while| loop, we never will, since nothing else will happen during JS

Comment 33

16 years ago
Well, I borrowed this test case from url originally reported
and this bug is actually a side affect of prematurely firing onLoad handler in
some cases when we render replaced element on the page.
I doubt this patch could cause any significant performance hit, we are doing
|ProcessReflowCommands| later anyway...
I'm investigating it right now.

Comment 34

16 years ago
Welp, what about something like this:

function foo() {
  document.write("<object type='replace/me'>
                   <embed id='plugin' type='valid/mime-type'></object>");
  tag = document.getElementById('plugin');

<BODY onLoad="foo()">

Delaying onLoad in this case is useless. I think we've got to move plugins to
content and create them syncronsly if accessed from the DOM.
That last part sounds like a great idea.  ;)

Comment 36

16 years ago
So what we currently do is in nsDOMClassInfo.cpp in |GetPluginInstance|, we:

1. FlushPendingNotifications() which causes content and frames to be created
2. GetPrimaryFrameFor() which returns the frame for this content
3. GetPluginInstance() on the object frame returns the plugin instance created
for this frame

Note: This may also fail in cases where the mime-type needs to be read from the
HTTP header.

Another idea is to possibly block layout (by pushing an event queue??) at this
point until we know what's going to happen with the plugin.
If plugin instantiation happens from content then that would be safe, assuming
the content tree doesn't mind being modified in the middle of the content
creation operation that creates the plugin (same problem as bug 136927).

Comment 38

16 years ago
IFRAME loading is kicked off in nsIContent::SetDocument which jst suggested may
also be a good place to start loading the plugin. At first glance at the stack,
that seems like it would be safe:

nsGenericElement::SetDocument(nsGenericElement * co
nsGenericElement::SetDocument(nsGenericElement * co
nsDocument::SetScriptGlobalObject(nsDocument * cons
DocumentViewerImpl::Close(DocumentViewerImpl * c
nsDocShell::SetupNewViewer(nsDocShell * const 0x034
nsDocShell::Embed(nsDocShell * const 0x0347b7ec, nsI
nsDocShell::CreateContentViewer(nsDocShell * const 0
nsDocumentOpenInfo::DispatchContent(nsIRequest * 0x
nsFileChannel::OnStartRequest(nsFileChannel * const 0x
nsOnStartRequestEvent::HandleEvent() line 161 + 53 by

...or we can possible use a single PLEvent and pull it out of the queue if
scripted. I think we still may still need a way to block for the case in which
the mime type needs to be read fro the HTTP header and the plugin gets scripted.

Comment 39

16 years ago
*** Bug 184126 has been marked as a duplicate of this bug. ***

Comment 40

16 years ago
hang also occurs with linux
OS: Windows 98 → All

Comment 41

14 years ago
I revisited today the page and it seems to work fine (no freezes, normal CPU
usage) with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5)
Gecko/20041113 and Mozilla/5.0 (Windows; U; Windows NT 5.0; es-ES; rv:1.7.5)
Gecko/20041108 Firefox/1.0, both with Shockwave Flash 7.0 r19. Although the pase
doesn't seem to have changed, it also tired the test cases here, and they all work.
Please confirm so I can mark this as fixed :-).

Comment 42

14 years ago
As no patch has been applied, resolving as WFM  (see previous comment). I think
the error message appearing too late issue was related to bug 13350.
Last Resolved: 16 years ago14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.