Closed Bug 62778 Opened 24 years ago Closed 24 years ago

Window status does not update js loop count, appears hung

Categories

(Core :: JavaScript Engine, defect, P3)

defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: dunn5557, Assigned: jst)

References

Details

(Keywords: arch, hang)

<!--
Window status does not update js loop count, appears hung.
This is a Backward Compatibility issue since the behavior
works as expected in Netscape 4.x.

Steps.
1. Create new HTML document, "test.html", with below text.
2. Open test.html using Netscape 4.7 and / or IE 5.x.
==> Notice: status is updated with the loop count as loop progresses.
3. Open test.html using Netscape 6.x

Result.
Window status never updates with the js loop count.
Browser appears hung until iteration completes.
-->

<!----copy - Paste to new HTML DOC ----->
<!DOCTYPE HTML PUBLIC "-//w3c//DVD HTML 3.2 Final//EN">
<html>
<head>
<title>Status within JS loop bug</title>
</head>
<body>
	<h1><align="Left">Status should be incrementing with a loop count.</h1>
	<hr>
	<p>
	<SCRIPT LANGUAGE="JAVASCRIPT">
	for (i=0; i<5001; i++) {
		window.status=("The current loop count: " + i + " iterations.");
	}
	document.write("The last loop count: " + (i-1) + " iterations.");
	</script>
	
</body>
</html>
<!------------------------------------>
over to jst for a look.
Assignee: asa → jst
Status: UNCONFIRMED → NEW
Ever confirmed: true
We can't fix this in mozilla, the reason this works in 4.x is that JS runs on
its own thread so the UI stays responsive while JS loops run but in mozilla JS
runs on the main thread which makes any JS block the main thread untill the JS
is done, because of this mozilla never has a chance to draw/paint the new status
message while the JS loop is running.

WONTFIX.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Why can't we move javascript that affects a page into some netwerk provider 
instead?

IMO there does not seem to be a good reason for page javascript to run in the 
gui thread.

Brendan: This is very bad (tm)

Marking Critical, blocking 30942 "Browser should remain responsive during most 
infinite loops" [yes I know this is not an infinite loop, but someone could use 
similar code to make it an infinite loop]. keywords: arch, hang

Moving out of B-G. CC people, and Reopen.
Blocks: 30942
Severity: major → critical
Status: RESOLVED → REOPENED
Component: Browser-General → Javascript Engine
Keywords: arch, hang
OS: Windows NT → All
QA Contact: doronr → pschwartau
Hardware: PC → All
Resolution: WONTFIX → ---
Moving the execution of JS in web pages from the main thread is something that
should've been done from the beginning in mozilla if it's something that was
ever gonna be done, putting JS on the main thread was a design decition that was
made early on to avoid all the nasty thread synchronization stuff that went on
in 4.x. Changing this is not something that can be done just like that, if it's
done it means that everything that JS can and will call must be thread safe,
that includes the whole DOM and everthing that the internal DOM code relies on.
This just won't happen any time soon if ever, and there's not a really good
reason for doing it either. If we wanna redesign things from the bottom up then
fine, we could move JS off the main thread but changing the way mozilla executes
JS today won't change any time soon. Won't fix.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WONTFIX
I agree that we shouldn't move JS out of the main thread any time soon.

However, can we make this looping testcase behave better?  Is there a way to
synchronously update the status bar and repaint from within the native setter
for window.status?  Can the branch callback help (for this loop, it will do a
JS_MaybeGC once at the 4096th iteration)?

/be
We let non-modal windows re-paint while a modal window is flying, right?  That
gives me hope that we can do something for the particular problem described in
this bug's Summary.

/be
> there's not a really good reason for doing it either.

IMO, this bug is a very good reason.

<rant>
I find it disappointing that Mozilla such problems.
</rant>
BenB: your rants need more humor and bitterness -- "I find it disappointing..."
is on the order of "Dear Sir / You Cur" ;-)

What does Opera do?  Anyone have other browsers that handle JS to try?

We can reopen this if someone shows a good way to pump certain events (similar
to those that get serviced on other windows when a modal window is flying) from
the branch callback, and maybe make the status bar painting synchronous, at
least when the status bar is updated directly from JS.

/be
> your rants need more humor and bitterness

That's probably, because it wasn't really a rant - I'm not bitter in this regard
yet. That's probably because I'm not sure about the scope of this bug.

What I do see all the time and am seriously worried about is the flakyness of
the UI, which seems to me being caused by lack of threadiness. E.g. I open the
(large) bookmarks menu, and you can see all of the UI - throbber, caret etc. -
suddenly stalling until the menu opened.
And this is not even to start with different top-level windows stalling each
other. E.g. while I resort the thread pane or open a new browser window, the
whole application is completely unusable - everything just stops until (most of)
the action is completed.
I hoped that this is just because Mozilla is still immature and it will be fixed
over time. But I can't understand why you would design a app in 1998/99 without
making it completely threaded. Sure it's more work, but users can see the result
- it gives a smoother app. And it excludes problems like this bug.

Back obtopic, it I'm right with my assumption above and the problem in this bug
has the same cause as the problems I described, then we should IMO fix the
threading. If it's a redesign, then for 2.0. (IMO, "n.0" should imply redesign
anyway :) .)
Could this bug maybe be fixed without changing threads? Bug 30942 suggests to
insert calls to the event loop in central places of JS execution. This would
ensure drawing of windows, not?
You need to log in before you can comment on or make changes to this bug.