[webkit-dev] ExecState::thisObject()

[Maciej Stachowiak]

On Jul 13, 2009, at 4:11 PM, Adam Barth wrote:

> On Mon, Jul 13, 2009 at 4:01 PM, Geoffrey Garen<ggaren at apple.com>  
> wrote:
>>> That's correct.  Other browser's get this case right.  Here are a
>>> couple test cases you might find interesting:
>>>
>>> http://webblaze.org/abarth/tests/protoconfused/test1.html
>>> http://webblaze.org/abarth/tests/protoconfused/test2.html
>>
>> I tried these tests, with mixed results:
>>
>> IE8: Exception thrown during load.
>> Firefox 3.0: mixture of passes and fails on test1.html. Exception  
>> thrown
>> during load of test2.html.
>> Chrome 2.0: Mixture of passes and fails.
>
> Yes.  All the browsers suck on these tests.  :)
>
> Would you like me to go look for more exploitable cases?  It seems
> like the only reason not to fix this issue is because we're afraid of
> code churn.

My own interest would be in weighing the tradeoffs. In the Pro column:

1) Are there aspects of this issue that create security holes?
2) Are there aspects of this issue that create Web compatibility  
problems?
3) Would enforcing a new consistent behavior for this reduce the  
likelihood of future mistakes that cause material problems?

In the potential Con column:

A) Will there be a performance or memory penalty?
B) Will the change increase code complexity?
C) Is there a risk of introducing regressions with the change?


If the benefits are high, then it's not that important to assess the  
risks - we will just live with them. If the benefits are low but the  
costs are also low, then I'd say having logical behavior wins out.  
It's only if the costs are high and the benefits are low that I'd be  
concerned about making the change at all. I wouldn't say "code churn"  
is categorically ruled out.

Personally I am convinced that the answers to (3) and (C) are both  
"yes", and I don't know about any of the other points.

Regards,
Maciej