Modal dialog doesn't threads to sleep in Firefox?

[VK]

Yet about the code posted at
<http://groups.google.com/group/comp..._frm/thread/bf33c7bbb9f699f9/0336cb59fb5920c5>

I just noticed another thing I did not notice last year (besides my
interface bug

I looks like in Firefox window.confirm does not put setTimeout
"threads" on sleep. Script keeps executing as never nothing. I presume
(did not test yet) that window.alert / window.prompt do the same.

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'm wondering if this Firefox behavior is intentional and mentioned
anywhere?

 

[Jonas Raoni]

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.

The confirm/alert/prompt should interrupt just the current code from
running, not all the processes. Take a look on the JavaScript reference
(not manuals) and check what it says.

 

[VK]

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.

I did, including mozilla.org. The same 11-years-old baby talk going
over and over for years: "this window has these buttons and returns
that, this window has those buttons and.. etc." Not a dot seems changed
since JavaScript 1.0

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

 

[Jonas Raoni]

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 ... !@#$%

Yes, that's great hehe, but we already make a lot of tricks haha. You
could write a wrapper: "window.setTimeout = function", then it would be
easier to manage ;]

Well, till now I haven't needed any kind of "synchronized" timer, so
this behaviour won't be important for me. If you're counting time, the
best solution is to subtract date intervals, since timers don't fire at
the exact interval that you setted.

"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.

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.

 

[VK]

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.

You mean Firefox makers will try to *guess* the right behavior?
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.

 

[Jonas Raoni]

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.

Ok, good luck, 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.

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).

alert([1, , null].length);

 

[VK]

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).

Yeh... more interesting. Looks like the engine threads comma
differently with or without elements.

If no one array element provided it executes it as comma operator:
arrayObject[0] = (undefined, undefined, undefined); // undefined

If at least one element provided, then it treats comma as elements
separator.

Seems like an inconsistency bug. Thanks for a tip for my " 'round array
" collection.

 

[Richard Cornford]

Jonas Raoni wrote:

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

And this one:

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

Should be 1.

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

Should be 2.

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.

 

[Jonas Raoni]

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.

Did you say it isn't a bug? Feel free to find it
<URL:https://bugzilla.mozilla.org>, I received an email some days ago
saying that it was going to be corrected.

The Firefox and Opera accept more parameters on the setTimeout, these
extra arguments are passed to the callback, so
"setTimeout(function(x){alert(x);}, 0, null);" would solve the problem,
I thought it was a kind of "real delay", but it's really a bug...

Well, there are a lot of incompatibilities between the browsers, so if
you start asking them what's the right way, open a text editor and start
writing all the different features :b

Another one
alert(new Array(5).splice(0).join("x"));

 

[Jonas Raoni]

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/

Anyway, in my opinion the last element should exist, it looks like:

{a: 0,};

or

var a, ;

Which generates errors.

 

[Richard Cornford]

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

<snip>

A software bug is not determined by a personal opinion. JavaScript(tm)
and JScript both claim to implement ECMA 262 so the one that is not
doing what is specified in ECMA 262 is the one with the bug.

Given the choice I would have the final comma define an additional
element, though if all implementations followed the standard it would
make machine generating array definitions easier as you would not have
to omit a comma after the final element to avoid creating an array that
was longer than intended. But the language is defined as the language is
defined so the situation is past the point where my opinion matters.

Richard.