W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2008

[whatwg] Preventing nested click() calls

From: Antti Koivisto <antti@apple.com>
Date: Mon, 17 Mar 2008 15:24:29 -0700
Message-ID: <5B1473FB-02EF-4D0A-9243-CD085B771BA7@apple.com>
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 <annevk at opera.com>  
> wrote:
>> On Mon, 10 Mar 2008 19:49:21 +0100, Antti Koivisto  
>> <antti at apple.com> 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
Received on Monday, 17 March 2008 15:24:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:40 UTC