|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
|
|
What really happens when you do javascript "alert()" in Firefox (or in other browsers)?Hi all,
I have some question on the behavior of javascript function alert() in the firefox browser. I don't if I am posting to the right forum. Please tell me if I should post it anywhere else. So here is the problem: Everyone is talking about that there is only a single thread for interpreting the javascript code for each page. That means you should not be able to create interleaving behavior, for example for two piece of code attached to two different event handler. However, you can some how create interleaving behavior by "alert()", here is the example: Suppose we defined a function Callpage() which use XMLHttpRequest to request another page asynchronously. on the request return, It will execute the callback registered in "onreadystatechange". Now we execute in onclick event of some button the following code: Callpage(); alert("abc"); alert("def"); A wired behavior can be observed in the Firefox is that, when "abc" pops up, if we do not click OK, wait for Callpage's request return, then the callback will be executed immediately, without waiting the current piece of code being finished. that is alert("abc")->callback execution->alert("def") Actually you can observe different behavior in different browser, for example in Google Chrome, you can only observe: alert("abc")->alert("def")->callback execution So the questions are: What do alert do in Firefox? My intuition is that alert() will pack the current continuation, and add a event for clicking the OK buttion, and when it returns, it will execute the continuation. Then the single thread story is still not broken. However, since call-with- continuation is not native in SpiderMonkey, it still bothers me how it is actually implemented. Thanks for reading, your comments are welcome. Zhengqin _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: What really happens when you do javascript "alert()" in Firefox (or in other browsers)?On 11/2/09 6:05 AM, Zhengqin wrote:
> What do alert do in Firefox? My intuition is that alert() will pack > the current continuation, and add a event for clicking the OK buttion, > and when it returns, it will execute the continuation. From the JS engine point of view, alert() simply blocks. That is, the JS engine calls a native function which then goes and puts up a modal dialog, etc, etc. That function doesn't return until after the user clicks the OK buton in the alert. Now it happens that the native function spins the event loop, which can process network events (hence your XHR thing) and user events (hence being able to click on the OK button at all). This can cause the JS engine to be reentered, as you observed. All this happens on a single thread. -Boris _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: What really happens when you do javascript "alert()" in Firefox (or in other browsers)?On 11/02/2009 05:05 AM, Zhengqin wrote:
> [...] you can some how create interleaving behavior by "alert()", > [...] > Callpage(); > alert("abc"); > alert("def"); > > A wired behavior can be observed in the Firefox is that, when "abc" > pops up, if we do not click OK, wait for Callpage's request return, > then the callback will be executed immediately, without waiting the > current piece of code being finished. that is > alert("abc")->callback execution->alert("def") > > Actually you can observe different behavior in different browser, for > example in Google Chrome, you can only observe: > alert("abc")->alert("def")->callback execution It's a bug. Chrome is doing it right. The property we're violating here is called "run to completion": the browser is supposed to run one script or event handler at a time and let it run until it finishes. I think this bug is pretty well-known at Mozilla, but I can't find it in Bugzilla. -j _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: What really happens when you do javascript "alert()" in Firefox (or in other browsers)?On 11/2/09 12:45 PM, Jason Orendorff wrote:
> It's a bug. Chrome is doing it right. I don't believe we consider it to be a bug. Modal dialogs such as alert() and confirm(), as well as window.openDialog and synchronous XMLHttpRequest do not guarantee that your script will run to completion without intervention from other script. --BDS _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: What really happens when you do javascript "alert()" in Firefox (or in other browsers)?On Nov 2, 6:57 pm, Benjamin Smedberg <benja...@...> wrote:
> On 11/2/09 12:45 PM, Jason Orendorff wrote: > > > It's a bug. Chrome is doing it right. > > I don't believe we consider it to be a bug. Modal dialogs such as alert() > and confirm(), as well as window.openDialog and synchronous XMLHttpRequest > do not guarantee that your script will run to completion without > intervention from other script. > > --BDS Thanks for all the answer above! However, whether alert() will complete or not only depend on user clicking it. If some other script is permitted to run at this time, it might create some unwanted interleaving for two piece of script (bad example as data-race), making it harder to reason about the behaviors of your script. Zhengqin _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: What really happens when you do javascript "alert()" in Firefox (or in other browsers)?Zhengqin wrote:
> On Nov 2, 6:57 pm, Benjamin Smedberg <benja...@...> wrote: >> On 11/2/09 12:45 PM, Jason Orendorff wrote: >> >>> It's a bug. Chrome is doing it right. >> I don't believe we consider it to be a bug. Modal dialogs such as alert() >> and confirm(), as well as window.openDialog and synchronous XMLHttpRequest >> do not guarantee that your script will run to completion without >> intervention from other script. >> >> --BDS > > Thanks for all the answer above! > > However, whether alert() will complete or not only depend on user > clicking it. If some other script is permitted to run at this time, it > might create some unwanted interleaving for two piece of script (bad > example as data-race), making it harder to reason about the behaviors > of your script. But this is not at all different just because it happens to be 'alert()'. On event runs up to the alert. Another event runs. Later the rest of the alert event handler runs. No big deal. If you are counting on something on one event handler changing when you are running on another, then you better be testing for the change. Thankfully you can use ordinary tests, no thread synchronization issues need concern you. jjb > > Zhengqin _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
| Free embeddable forum powered by Nabble | Forum Help |