In what ways does the following "eval" regularity break?
mjs at apple.com
Thu Oct 30 13:24:12 PDT 2008
On Oct 30, 2008, at 1:09 PM, Brendan Eich wrote:
> On Oct 30, 2008, at 12:58 PM, Maciej Stachowiak wrote:
>> On Oct 30, 2008, at 12:24 PM, Brendan Eich wrote:
>>> Probably when we started, we had the Firefox 1.0-1.5 behavior
>>> (JS1.5-1.6) in mind. Since then, elves "fixed" bugs. :-/
>>> Still I do not know of web content that calls indirect eval and
>>> expects local eval. Gmail did (and may still) due to its cruncher
>>> do something like
>>> var Ae = eval;... Ae(s)
>>> but the program in string s wanted only global scope.
>> We have not found compatibility issues since we converted indirect
>> eval to global eval in WebKit. (We have about 10,000 regular
>> nightly users so it's had some test coverage, but that is still a
>> fair bit less than a public beta or a full release version.) I
>> believe what we have now matches the old proposed ES4 behavior.
>> Brendan, do you know if the Mozilla change on this was for reasons
>> of Web compatibility?
> Not exactly. I believe the change was an unintended consequence of
> fixing a series of bugs that did not explicitly request that
> indirect eval be local. These bugs involved, e.g. Prototype (the JS
> library) and its Ajax.Updater (with evalScripts set to true). The
What's the expected behavior for this reduction?
> As I wrote in another post today, we would gladly go back to the
> JS1.5-1.6-era indirect-eval-is-global behavior if it were
> standardized. We would not be glad about any standard that required
> indirect eval to be "operator eval". No doubt you feel the same way!
Yes, we would prefer that the standard require indirect eval to be
global, and would not like the standard require it to be local.
The reason I asked about the change in Mozilla behavior was to see if
we had evidence of this behavior not being Web-compatible; but it
More information about the Es-discuss