hang if "window.find()" is called in a "while(true)" loop of a javascript

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
--
critical
14 years ago
9 years ago

People

(Reporter: Tobias Etragleo, Unassigned)

Tracking

(Depends on: 1 bug, {hang, testcase})

Trunk
x86
All
hang, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

323 bytes, text/html
Details
(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.7.1) Gecko/20040707
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.7.1) Gecko/20040707

On some page mozilla crashes and i saw a short time before the find window.
Today i found the same bug again on a old Documentation-CD. Some sort of script
popup the window.find() dialog again and again. (It's a bug of the script, but
mozilla crashes)

Reproducible: Always
Steps to Reproduce:
1. Create a simple HTML-Page (listed below)
2. Start Mozilla and open the page.

Actual Results:  
Mozilla crashes imediatly

Expected Results:  
the search dialog should be enabled only once, or not without user interaction.

The following code is an example of a script that crashes Mozilla:

<html><head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="content-type"><title>Testpage</title>

<script language="JavaScript">
while(true) {
window.find(location.search.substring(1));
}
</script></head>

<body onload="---window.find(location.search.substring(1));">
Testpage<br>
<br>
</body></html>

Comment 1

14 years ago
The problem is not with JS Engine, but that multiple find dialogs can be opened.
Each call to window.find() opens a new dialog.

confirmed with linux trunk 2004102606

==> DOM0
Assignee: general → general
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → DOM: Level 0
Ever confirmed: true
Keywords: crash, testcase
OS: Windows 2000 → All
QA Contact: pschwartau → ian
> Each call to window.find() opens a new dialog.

We have code to prevent that...  See  GlobalWindowImpl::FindInternal.  Why is
that failing?

Comment 3

14 years ago
I noticed the bug only happens when multiple dialogs are opened before the
script finishes.  And the dialogs don't actually open (they aren't visible)
until the script is finished.  For instance, using setInterval to repeatedly
open dialogs doesn't trigger this bug.
Ah, I see.  So the problem is that the dialogs open async, so the global window
code thinks the dialog is not open yet, but it's in the process of opening...

danm, what can we do here?

Comment 5

14 years ago
I don't see anything for it but to open chrome windows synchronously.
(Reporter)

Comment 6

14 years ago
Is there no way to prevent this?

The Bug is now older then 2 Month, and still not fixed. I have not the ability
to fix it, but it can't be so difficult. (C/C++ is not my strength :o)

Is it not easy to synchronize a opening windows?
Sorry, but it hurts me, that nothing happens.

(In reply to comment #6)
> but it can't be so difficult.

Sorry, but this statement is flat-out wrong.

> Is it not easy to synchronize a opening windows?

No, it's not.  It's a pretty huge undertaking, and undesirable to boot, in
general.  If we only do it for chrome, we have two different window-opening
codepaths, with different semantics... it's a mess.

One other option here is to have the Find dialog let the opener know when it
goes away.  This way the window could set a flag when it makes the open call,
and ignore new calls to find() while that flag is set, then unset it when the
find dialog notifies it that it's closing.

Updated

14 years ago
Depends on: 279670

Comment 8

13 years ago
Boris, Dan M, you may want to take a look at to bug 321880, which I just filed. It seems related, although the Javascript concurrency seemingly going on may indicate some additional bug in DOM event processing.

Comment 9

12 years ago
Created attachment 224137 [details]
testcase

Comment 10

12 years ago
testcase wfm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060601 Minefield/3.0a1 ID:2006060105 [cairo]

Comment 11

12 years ago
Created attachment 224155 [details]
testcase

This exhibits the bug (but only tries to open 3 dialogs) with linux seamonkey trunk 2006060108.
Attachment #224137 - Attachment is obsolete: true
Assignee: general → nobody
QA Contact: ian → general

Comment 12

9 years ago
I can't get this to crash on Mac using mozilla-central.  It does fine closing 3 or 10 windows.  Is it still crashing on Linux, or has this turned into a non-crash bug?

Updated

9 years ago
Whiteboard: [needs retesting on linux]

Comment 13

9 years ago
I think
1) "crash" meant "hang" (in javascript) -- oops
2) "failure" for the testcase meant successfully opening 3 dialogs.  if the bug goes away, the testcase should either open only 1 dialog or perhaps open 3 dialogs sequentially (which wouldn't really be a dramatic improvement, but perhaps a different bug).

You can download the testcase and modify it to open more (or just use a while(true) loop) to get the full effect of the bug.

The behavior of the testcase (and a more aggressive one that opens lots of windows) hasn't changed since the original report AFAICT.
Keywords: crash → hang
Summary: crash if "window.find()" is called in a "while(true)" loop of a javascript → hang if "window.find()" is called in a "while(true)" loop of a javascript
Whiteboard: [needs retesting on linux]
You need to log in before you can comment on or make changes to this bug.