Modal dialog doesn't threads to sleep in Firefox?

I realize that "window is not documented, and setTimeout is not
documented and ta-ta-ta". Still IMHO *the most expected* behavior IMHO
is that demonstrated by IE and Opera:- all threads are sleeping until
you dismiss the dialog.

I've just tested what you said and in my opinion the Firefox behaviour
is better. If I start a timer, it doesnt matter what's happening, I want
it to keep running until I tell it to stop.
It is not really a question of better/worse, but a question of
consistency. With 10-100 "threads" running, a single alert will move FF
and IE to completely different time frames after dialog is closed.
What is more benefitial programmatically - it highly depends of course
on the current task. I personally consider Firefox behavior as more
"adult looking". At the same time JavaScript doesn't have real *thread*
management and synchronization like in Java, so seems like a rather
dangerous decision to me especially for multiple timed instance
methods.
Not too much one can do anyway. It's great good to know though. So I
guess to have cross-browser FF behavior one needs to use a DHTML widget
instead. And for cross-browser IE/Opera/Co behavior one needs to stop
all "thread" manually before showing a dialog - and manually resume
them after.
Just great ... !@#$% ...
Take a look on the JavaScript reference
(not manuals) and check what it says.

Jonas Raoni wrote:

I've just tested what you said and in my opinion the Firefox behaviour
is better. If I start a timer, it doesnt matter what's happening, I want
it to keep running until I tell it to stop.
It is not really a question of better/worse, but a question of
consistency.

Ok, I thought you were just alerting about this fact, not asking about
solutions.
With 10-100 "threads" running, a single alert will move FF
and IE to completely different time frames after dialog is closed.
Sure.
I personally consider Firefox behavior as more "adult looking".
I prefer it too, but since there's nothing on the specification (you
said), it would be nice to keep the same behaviour.
At the same time JavaScript doesn't have real *thread*
management and synchronization like in Java
It doesn't matter, JavaScript was used to validate forms not to build
powerful applications, try to take a look on the JS 2.0, maybe there's
something new =)
So I guess to have cross-browser FF behavior one needs to use a DHTML widget
instead.
But you won't be able to achieve the same result =/

myConfirm("Are you sure?");
confirm("Are you sure?");

Won't be the same as:

confirm("Are you sure?");
myConfirm("Are you sure?");

And for cross-browser IE/Opera/Co behavior one needs to stop
all "thread" manually before showing a dialog - and manually resume
them after.
Just great ... !@#$%

Take a look on the JavaScript reference
(not manuals) and check what it says.

"this window has these buttons and returns
that, this window has those buttons and.. etc."

I think I'll ask at bugzilla: not as a bug report, but as a
clarification request.

VK wrote:

I think I'll ask at bugzilla: not as a bug report, but as a
clarification request.

Well, if there's nothing talking about this on the specification, it's
unuseful to ask to the Firefox crew. It won't be a right answer, since
it will be based on guessing.

Jonas Raoni wrote:

Well, if there's nothing talking about this on the specification, it's
unuseful to ask to the Firefox crew. It won't be a right answer, since
it will be based on guessing.

I just want to check that they are aware of this behavior, that it is
by design so will stay from version to version, and not a particular
version specific.

I warned them about some bizarre bugs that I found, but I
don't remember of all of them, just 2:

This one:
setTimeout(function(x){alert(x);}, 0);

My function had other ways of beeing used, so when there was no
arguments, I supposed it was invoked by a timer.
Well the above is a side effect of what I called "NOOP" in
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/bf33c7bbb9f699f9>

setTimeout is running as kind of
with(window) {eval(arg);}
(language purists: I said "kind of" :-)

.... so sweet heart closures do not do much of good.
And this one:

alert([,].length); //should be 2
alert([,,].length); //should be 3

I had to add a 0/null in the end of my not so null arrays (it just
ignores the last null value).

... , I warned them about some bizarre bugs that I found,
but I don't remember of all of them, just 2: <snip> And this one:

alert([,].length); //should be 2
Should be 1.
alert([,,].length); //should be 3

Jonas Raoni wrote:

setTimeout(function(x){alert(x);}, 0);

Well the above is a side effect of what I called "NOOP" in
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/bf33c7bbb9f699f9>

setTimeout is running as kind of
with(window) {eval(arg);}
(language purists: I said "kind of" :-)

... so sweet heart closures do not do much of good.

Jonas Raoni wrote:
<snip>
A final comma in an array literal does not imply a following element.
Mozilla is correct here and JScript is the implementation with the bug.

Richard Cornford wrote:

Jonas Raoni wrote:
<snip>
A final comma in an array literal does not imply a following
element. Mozilla is correct here and JScript is the
implementation with the bug.

Great, someone has read the specs instead of testing and guessing
what would be the best way in its own opinion \o/