Re: [whatwg] Preventing nested click() calls
On Mon, 10 Mar 2008, Antti Koivisto wrote: WebKit, Firefox and IE all implement a protection mechanism against re- entering click() on the same element: input type=checkbox onclick=this.click() WebKit (and based on testing Firefox) make click() a no-op when invoked as a result of a click event generated by calling click() on the same element. For IE this seems to be true even for user generated click events. On Fri, 14 Mar 2008, Erik Arvidsson wrote: To me it just seems wrong to prevent this. This is in theory no different than a recursive call and just like recursion it can end up in an infinite loop. Having a limit seems OK since most JavaScript engines already have a limit on the size of the call stack. On Fri, 14 Mar 2008, Antti Koivisto wrote: In practice all browsers already treat click() as a special case. Removing the nesting protection completely (and relying on js stack limits) would break web sites so it is not an option. The only question is whether the limit should be 1 or some other number. Matching the existing implementations and disallowing nesting seems like a right thing to do here. On Fri, 14 Mar 2008, Geoffrey Garen wrote: You're right, it is no different *in theory*. It is, however, different in practice. If we allow click() to re-enter itself, popular websites stop working. On Mon, 17 Mar 2008, Antti Koivisto wrote: Hixie asked for a concrete example of page that breaks if click() limit is removed so here is one: 1. Go to http://forums.whirlpool.net.au/ 2. Under Whirlpool (righthand side) go to 'Feedback Forum' 3. Click on any Forum 4. Click reply to this post (righthand) side 5. Login (you need to create an account) 6. Click 'Show quoted' box Without click() protection the last step hangs the browser (at least until javascript time limit kicks in). Script is sufficiently complex and slow to execute that it won't hit javascript stack limit. I tried having a minimum nesting limit that passes Acid3 (10 iterations) and that too produces a noticeable ~1s pause. On mobile class hardware that would be a complete hang. I've added the reentrancy block to HTML5. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Preventing nested click() calls
Hixie asked for a concrete example of page that breaks if click() limit is removed so here is one: 1. Go to http://forums.whirlpool.net.au/ 2. Under Whirlpool (righthand side) go to 'Feedback Forum' 3. Click on any Forum 4. Click reply to this post (righthand) side 5. Login (you need to create an account) 6. Click 'Show quoted' box Without click() protection the last step hangs the browser (at least until javascript time limit kicks in). Script is sufficiently complex and slow to execute that it won't hit javascript stack limit. I tried having a minimum nesting limit that passes Acid3 (10 iterations) and that too produces a noticeable ~1s pause. On mobile class hardware that would be a complete hang. antti On 14.3.2008, at 11:04, Erik Arvidsson wrote: To me it just seems wrong to prevent this. This is in theory no different than a recursive call and just like recursion it can end up in an infinite loop. Having a limit seems OK since most JavaScript engines already have a limit on the size of the call stack. On Mon, Mar 10, 2008 at 11:54, Anne van Kesteren [EMAIL PROTECTED] wrote: On Mon, 10 Mar 2008 19:49:21 +0100, Antti Koivisto [EMAIL PROTECTED] wrote: WebKit, Firefox and IE all implement a protection mechanism against re-entering click() on the same element: input type=checkbox onclick=this.click() Opera had the same restriction. We now limit it at 50 or so... I think we're fine either way though. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/ -- erik
Re: [whatwg] Preventing nested click() calls
To me it just seems wrong to prevent this. This is in theory no different than a recursive call and just like recursion it can end up in an infinite loop. Having a limit seems OK since most JavaScript engines already have a limit on the size of the call stack. On Mon, Mar 10, 2008 at 11:54, Anne van Kesteren [EMAIL PROTECTED] wrote: On Mon, 10 Mar 2008 19:49:21 +0100, Antti Koivisto [EMAIL PROTECTED] wrote: WebKit, Firefox and IE all implement a protection mechanism against re-entering click() on the same element: input type=checkbox onclick=this.click() Opera had the same restriction. We now limit it at 50 or so... I think we're fine either way though. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/ -- erik
Re: [whatwg] Preventing nested click() calls
In practice all browsers already treat click() as a special case. Removing the nesting protection completely (and relying on js stack limits) would break web sites so it is not an option. The only question is whether the limit should be 1 or some other number. Matching the existing implementations and disallowing nesting seems like a right thing to do here. antti On 14.3.2008, at 11:04, Erik Arvidsson wrote: To me it just seems wrong to prevent this. This is in theory no different than a recursive call and just like recursion it can end up in an infinite loop. Having a limit seems OK since most JavaScript engines already have a limit on the size of the call stack. On Mon, Mar 10, 2008 at 11:54, Anne van Kesteren [EMAIL PROTECTED] wrote: On Mon, 10 Mar 2008 19:49:21 +0100, Antti Koivisto [EMAIL PROTECTED] wrote: WebKit, Firefox and IE all implement a protection mechanism against re-entering click() on the same element: input type=checkbox onclick=this.click() Opera had the same restriction. We now limit it at 50 or so... I think we're fine either way though. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/ -- erik
Re: [whatwg] Preventing nested click() calls
To me it just seems wrong to prevent this. This is in theory no different than a recursive call and just like recursion it can end up in an infinite loop. You're right, it is no different *in theory*. It is, however, different in practice. If we allow click() to re-enter itself, popular websites stop working. Having a limit seems OK since most JavaScript engines already have a limit on the size of the call stack. The concern here isn't implementation complexity -- it's web compatibility. A standard that breaks the web is no standard at all. Geoff
[whatwg] Preventing nested click() calls
Hi, WebKit, Firefox and IE all implement a protection mechanism against re- entering click() on the same element: input type=checkbox onclick=this.click() WebKit (and based on testing Firefox) make click() a no-op when invoked as a result of a click event generated by calling click() on the same element. For IE this seems to be true even for user generated click events. HTML5 does not currently say anything about this so presumably nested click() calls are allowed. A subtest of test 73 of Acid3 specifically tests for this. Based on testing above shipping browsers treat click() as a special case. Changing this behavior to allow nested click() calls would be a significant regression risk. A better option would be specifying the click() nesting protection mechanism in HTML5. There are more discussion in http://bugs.webkit.org/show_bug.cgi?id=17083 antti
Re: [whatwg] Preventing nested click() calls
On Mon, 10 Mar 2008 19:49:21 +0100, Antti Koivisto [EMAIL PROTECTED] wrote: WebKit, Firefox and IE all implement a protection mechanism against re- entering click() on the same element: input type=checkbox onclick=this.click() Opera had the same restriction. We now limit it at 50 or so... I think we're fine either way though. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
