111097 - timeouts not blocked during prompt, alert, etc.

Status: RESOLVED DUPLICATE of bug 52209

(Core :: DOM: Core & HTML, defect, P5)

Description

[John Bandhauer]

In NS4.x and IE timeouts don't fire while waiting on the user in a modal prompt
or alert. In mozilla they do fire. This can lead to unexpected results.

Any fix for this ought to also address embedders' implementations of the prompt
stuff. And, it ought to deal with prompts that are the result of asking the caps
systems for security priviledges.

I'll attach a test case that shows we are not blocking in mozilla (or mfcEmbed
for that matter).

Comment 1

[John Bandhauer]

Attachment: test case showing that timeouts fire

Comment 2

[Colin Phillips]

I think this is a great feature.  This allows the calendar to fire alerts when
an event comes up.  I don't think this should be changed.

Comment 3

[Dan M]

The problem is only Mozilla behaves this way; it's a compatibility and
repeatability issue among the different browsers.

Comment 4

[Colin Phillips]

True, but no other "browser" has a calendar either.  So should that not be
included just because only Mozilla has that?  Hardly.

What does the W3C spec say?

Comment 5

[Johnny Stenback (:jst)]

This is not a feature, it's a bug. There are no W3C specs that specify how this
should work, but modal dialogs are modal dialogs, having many of them pop up at
the same time is just wrong.

Comment 6

[Colin Phillips]

That may be true, but the w3c spec should specify how setTimeout should work...

Comment 7

[Johnny Stenback (:jst)]

People have been arguing about whether or not the W3C should define what the
|window| object is for years, and so far the decision has been "no". Feel free
to pick up that discussion again with W3C if you want to (read the mailinglist
archives before you do that tho), but this bug is not the place for that.

Comment 8

[bht237]

I have been assuming that JavaScript applications are single-threaded from the
perspective of the application.
In my experience, non-blocking behavior in JavaScript seems to always open a can
of worms such as the non-blocking buggy behavior of window.open() in MSIE.
The idea of "true" concurrency might be cool but without language support e.g.
monitors it would be quite dangerous (security errors and crashes) to have such
functionality.
I have actually seen Mozilla crash only after multiple alert boxes accumulated.

So I am glad this is a bug and not a feature and I would not be surprised if
other crashes disappear as a result of fixing this one.

Comment 9

[José Jeria]

How about? :
Keywords: 4xp
Platform/OS: All/All
Severity: Major

Comment 10

[bht237]

Refer to bug 178810 for a crash case.

Comment 11

[timeless]

*** Bug 186883 has been marked as a duplicate of this bug. ***

Comment 12

[José Jeria]

Dupe of bug 60150 [ Modal dialogs (alert, confirm, prompt) do not halt code
execution ] ?

Comment 13

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 14

[Firefox Bug Husbandry Bot]

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.