Closed
Bug 266324
Opened 20 years ago
Closed 3 years ago
hang if "window.find()" is called in a "while(true)" loop of a javascript
Categories
(Core :: DOM: Core & HTML, defect, P5)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: Tobain, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: hang, testcase)
Attachments
(1 file, 1 obsolete file)
|
323 bytes,
text/html
|
Details |
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•20 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
|
||
Comment 2•20 years ago
|
||
> Each call to window.find() opens a new dialog.
We have code to prevent that... See GlobalWindowImpl::FindInternal. Why is
that failing?|
|
||
Comment 3•20 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.
|
|
||
Comment 4•20 years ago
|
||
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?
I don't see anything for it but to open chrome windows synchronously.
|
Reporter | |
Comment 6•20 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.
|
|
||
Comment 7•20 years ago
|
||
(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.
|
||
Comment 8•19 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•18 years ago
|
||
|
|
||
Comment 10•18 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•18 years ago
|
||
This exhibits the bug (but only tries to open 3 dialogs) with linux seamonkey trunk 2006060108.
Attachment #224137 -
Attachment is obsolete: true
|
||
Updated•15 years ago
|
Assignee: general → nobody
QA Contact: ian → general
|
||
Comment 12•15 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•15 years ago
|
Whiteboard: [needs retesting on linux]
|
|
||
Comment 13•15 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.
|
||
Comment 14•6 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
|
||
Comment 15•3 years ago
|
||
Really old bug, can't reproduce this on the latest Firefox Nightly on macOS 10.15 with the attached testcase. Closing this as resvoled:worksforme but please de re-open in case it is still reproducible on the latest Firefox versions.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•