If we don't end up emails with questions, maybe? :P
Thanks Boris for the improved report bug in webkit.
Best Regards
Sent from my Windows PhoneFrom: Brendan Eich
Sent: 9/9/2014 0:10
To: Andrea Giammarchi
Cc: Mark Miller; Mark S. Miller; es-discuss list
Subject: Re: "use strict"
Boris Zbarsky wrote:
Though again, IE9 and before use that wrong window. So it's at least
_possible_ that UAs could change to that behavior (change back, in the
case of IE).
What, my "original intent" argument didn't work? :-P
http://arstechnica.com/information-technology/2014/09/august-grow
On 9/8/14, 7:10 PM, Brendan Eich wrote:
The point here is that otherWin.setTimeout(func, ...) must -- because of
"is" not "ought" -- not pass undefined to func in case it is strict
mode, because if it's sloppy and if it is scoped by the current window
(not otherWin), then the wrong window will be
On 9/8/14, 6:49 PM, Mark S. Miller wrote:
Let's just be sure that we avoid this mistake when promises grow
something like Q's Q.delay. Promise.delay? Promise.prototype.delay?
Yes, absolutely. This is why requestAnimationFrame is specced to pass
undefined for "this", implementation bugs notwit
Andrea Giammarchi wrote:
Thanks for the background history, however I am still not sold the
fact it's a global object method should mean a global context should
be passed.
"Is" (or "was" and therefore "is" because "don't break the web") -- not
"ought".
You need a way out of Hume's Guillotin
On Mon, Sep 8, 2014 at 3:15 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Thanks for the background history, however I am still not sold the fact
> it's a global object method should mean a global context should be passed.
>
> Following, a snippet simulating what would be my expect
Thanks for the background history, however I am still not sold the fact
it's a global object method should mean a global context should be passed.
Following, a snippet simulating what would be my expectations
```js
window.myTimer = function (callback, delay) {
// queue the callback as the task
Mark Miller wrote:
Yes, this is indeed the only question that Andrea and I are raising in
this thread. As you acknowledge, providing window here is a little
strange. I quibble with "a little". When a surprise surprises by
providing less authority than expected, I don't much care. When the
surp
so far I've managed to file Chromium and WebKit only:
https://code.google.com/p/chromium/issues/detail?id=411959
https://bugs.webkit.org/show_bug.cgi?id=136635
with IE I've had some trouble finding a "file a bug" link ...
Best Regards
On Mon, Sep 8, 2014 at 5:53 PM, Mark S. Miller wrote:
> No,
No, this isn't an information disclosure or any other security issue. It is
"only" a modularity issue.
On Mon, Sep 8, 2014 at 9:49 AM, Jasvir Nagra wrote:
> On Mon, Sep 8, 2014 at 8:45 AM, Mark S. Miller wrote:
>
>> On Mon, Sep 8, 2014 at 8:35 AM, Andrea Giammarchi <
>> andrea.giammar...@gmai
On Mon, Sep 8, 2014 at 8:45 AM, Mark S. Miller wrote:
> On Mon, Sep 8, 2014 at 8:35 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Boris and Mark, I was talking about engines, already inevitably able to
>> distinguish strict from sloppy,
>>
>
> We have made great progress in J
On Mon, Sep 8, 2014 at 8:35 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Boris and Mark, I was talking about engines, already inevitably able to
> distinguish strict from sloppy,
>
We have made great progress in JS better able to implement/emulate the APIs
we expect browsers to p
Boris and Mark, I was talking about engines, already inevitably able to
distinguish strict from sloppy, but in any case in JS is straight forward
to know if you are under strict directive or not.
```js
var isStrictAvailable = (function(){'use strict';return !this}());
var isThisStrict = isStrictAv
On 9/8/14, 10:25 AM, Andrea Giammarchi wrote:
Apologies, now I see what you meant and I think option 2 would be
probably ideal. ES5+ engines can easily retrieve "strictness"
In script? How? (Again, clearly in the VM implementation I can do this.)
Going through the list of all properties it
On Mon, Sep 8, 2014 at 7:25 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Apologies, now I see what you meant and I think option 2 would be probably
> ideal.
>
I disagree. I think option #2 is rather horrible. Strictness can't be
tested in JS user code, and shouldn't be. And slopp
Apologies, now I see what you meant and I think option 2 would be probably
ideal. ES5+ engines can easily retrieve "strictness" so while it might seem
weird it would surprise less, syntax and explicit intent speaking, and will
remove the right to pass *a* global context to the callback.
Going thro
On 9/8/14, 8:15 AM, Andrea Giammarchi wrote:
no introspection or nothing magic and weird, simply `.call(undefined)`
would do for sloppy and strict, preserving global in sloppy, avoiding
shenanigans in strict.
You seem to be assuming there is only one global involved again. Did
you look at my
no introspection or nothing magic and weird, simply `.call(undefined)`
would do for sloppy and strict, preserving global in sloppy, avoiding
shenanigans in strict.
Hence my curiosity: when this experiment was made, which code with `"use
strict"` failed ? 'cause that would be the only one that eith
On 9/8/14, 3:50 AM, Andrea Giammarchi wrote:
I wonder what was breaking
I don't remember, unfortunately. :(
specially after showing there were
inconsistencies between browsers.
It's worth asking the IE team whether they changed because of concrete
web compat issues or just to align with t
for the heads up on the failing experiment. Curious to know
if ES5 at that time was popular.
Regards
Sent from my Windows Phone
--
From: Mark S. Miller
Sent: 9/8/2014 5:08
To: Boris Zbarsky
Cc: es-discuss
Subject: Re: "use strict" VS setTimeout
On
On 9/7/14, 9:35 PM, Boris Zbarsky wrote:
Now, and here's where I have a problem with your use of "the": the
Window that setTimeout is invoked on is NOT necessarily the same as the
global object of the function.
Just to make this concrete, see
http://fiddle.jshell.net/tmt5e9m6/2/show/ which has
On Sun, Sep 7, 2014 at 6:35 PM, Boris Zbarsky wrote:
> On 9/7/14, 1:29 PM, Andrea Giammarchi wrote:
>
>> I know this is probably W3C land but the following code shows the global
>> object
>>
>
> Careful with your use of the word "the". Your ES5-centric assumptions are
> showing. ;)
>
> The func
On 9/7/14, 1:29 PM, Andrea Giammarchi wrote:
I know this is probably W3C land but the following code shows the global
object
Careful with your use of the word "the". Your ES5-centric assumptions
are showing. ;)
The function passed to setTimeout will be invoked with "this" set to the
windo
On Sun, Sep 7, 2014 at 12:50 PM, Garrett Smith
wrote:
> On 9/7/14, Andrea Giammarchi wrote:
> > this is getting nowhere ... yeah Garret, you can use `.call` and we all
> > know that ...
> >
> > Now I want you to answer this: why on earth would you expect a global
> > context in a setTimeout or s
On 9/7/14, Andrea Giammarchi wrote:
> this is getting nowhere ... yeah Garret, you can use `.call` and we all
> know that ...
>
> Now I want you to answer this: why on earth would you expect a global
> context in a setTimeout or setInterval operation for a function/method you
> have explicitly def
this is getting nowhere ... yeah Garret, you can use `.call` and we all
know that ...
Now I want you to answer this: why on earth would you expect a global
context in a setTimeout or setInterval operation for a function/method you
have explicitly defined as strict ?
One single use case ... do you
On 9/7/14, Andrea Giammarchi wrote:
> **implicitly fail** from a user point of view that used "use strict" to
> avoid receiving the global context in there ... I am not sure how much you
> want to turn it back to me but you are missing the point and I've not much
> else to say.
>
"use strict" doe
I might try again but they'll probably tell me "specs say so, must be good"
as others here so not sure I should bother.
Thanks though.
Regards
On Sun, Sep 7, 2014 at 8:11 PM, Anne van Kesteren wrote:
> On Sun, Sep 7, 2014 at 9:06 PM, Andrea Giammarchi
> wrote:
> > Yes Anne, reason I've posted
On Sun, Sep 7, 2014 at 9:06 PM, Andrea Giammarchi
wrote:
> Yes Anne, reason I've posted here was to ask opinions from JS land + I am
> not sure it's that easy to post in W3C mailing list as random chap while
> here I'm already registered (and here I was looking for opinions beside what
> specs say
Yes Anne, reason I've posted here was to ask opinions from JS land + I am
not sure it's that easy to post in W3C mailing list as random chap while
here I'm already registered (and here I was looking for opinions beside
what specs say)
Good to see MM was already on fire in there :D
On Sun, Sep 7,
Garret for legacy we are good to go with `.call(undefined)` that will bring
window in there but `addEventListener` is a different intent/operation than
`setTimeout` plus you lways have `e.currentTarget` which is always
preferable anyway since this will not produce what you expect:
```js
addEventLi
On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
wrote:
> I know this is probably W3C land ...
First hit for "callback use strict inurl:lists.w3.org":
http://lists.w3.org/Archives/Public/public-script-coord/2011JulSep/thread.html#msg3
--
http://annevankesteren.nl/
___
(window), which is what the
>> spec does, will override it.
>>
>> As far as I can see this issue has absolutely nothing to do with strict
>> vs. sloppy.
>> --
>> From: Andrea Giammarchi
>> Sent: 2014-09-07 19:14
>>
On 9/7/14, Mark Miller wrote:
> On Sun, Sep 7, 2014 at 11:27 AM, Domenic Denicola <
> dome...@domenicdenicola.com> wrote:
>
>> I don't understand why this is any more surprising than any other
>> function that calls its callback with .call(something).
>>
>
> The issue is what the something should
___
From: Andrea Giammarchi<mailto:andrea.giammar...@gmail.com>
Sent: ?2014-?09-?07 19:14
To: Mark Miller<mailto:erig...@gmail.com>
Cc: Mark S. Miller<mailto:erig...@google.com>; es-discuss
list<mailto:es-discuss@mozilla.org>
Subject: Re: "use stric
the callback is strict or not; .call(window), which is what the
> spec does, will override it.
>
> As far as I can see this issue has absolutely nothing to do with strict
> vs. sloppy.
> --
> From: Andrea Giammarchi
> Sent: 2014-09-07 1
On Sun, Sep 7, 2014 at 11:44 AM, Garrett Smith
wrote:
> On 9/7/14, Domenic Denicola wrote:
> > I don't understand why this is any more surprising than any other
> function
> > that calls its callback with .call(something). It doesn't matter whether
> the
> > callback is strict or not; .call(wind
On Sun, Sep 7, 2014 at 11:27 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> I don't understand why this is any more surprising than any other
> function that calls its callback with .call(something).
>
The issue is what the something should be, and which choices for something
are s
gt;
> Cc: Mark S. Miller<mailto:erig...@google.com>; es-discuss
> list<mailto:es-discuss@mozilla.org>
> Subject: Re: "use strict" VS setTimeout
>
> It feels to me also a vector that will happily pass all linters and code
> analyzers giving users a door to reach nativ
I would add that in node.js it returns neither undefined nor window, but a timer object, which you can clear up with `clearInterval(this)` inside the callback. 07.09.2014, 21:30, "Andrea Giammarchi" :I know this is probably W3C land but the following code shows the global object in every JS engin
iscuss@mozilla.org>
Subject: Re: "use strict" VS setTimeout
It feels to me also a vector that will happily pass all linters and code
analyzers giving users a door to reach native context and start playing in
there with everything else. I'm pretty sure you would agree on this to
It feels to me also a vector that will happily pass all linters and code
analyzers giving users a door to reach native context and start playing in
there with everything else. I'm pretty sure you would agree on this too :)
Please let us know if there's any follow up, it's probably easier/faster if
On Sun, Sep 7, 2014 at 11:07 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Yes Axel, that's how it works, this will show undefined indeed all over
>
> ```js
> (function () {
> 'use strict';
> function g() {
> console.log(this);
> }
> g(); // undefined
> setTimeout(fun
Yes Axel, that's how it works, this will show undefined indeed all over
```js
(function () {
'use strict';
function g() {
console.log(this);
}
g(); // undefined
setTimeout(function () {
g(); // undefined
}, 0);
}());
```
or testing other use strict restrictions:
```js
(functi
On Sun, Sep 7, 2014 at 10:29 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> I know this is probably W3C land but the following code shows the global
> object in every JS engine I could test:
>
> ```js
> (function () {
> 'use strict';
> setTimeout(function () {
> 'use strict'
On Sep 7, 2014, at 19:47 , Mark S. Miller wrote:
> On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens wrote:
> On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
> wrote:
> > This looks like a potential problem when possible passed methods are not
> > bound + it looks inconsistent with *"use strict
My same thoughts on "break the web" ... I think whoever put "use strict" in
there would eventually never expect the `this` to be the global context.
@Michał Wadas ... you haven't proved much in there ... you should look at
global methods more like this:
```js
// your global context to be executed
`
var temp = window;
document.querySelector('iframe').contentWindow.setTimeout(function() {
console.log(temp === window); // false
})
`
setTimeout is a method of global object, not a standalone function.
2014-09-07 19:47 GMT+02:00 Mark S. Miller :
> On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens
On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens wrote:
> On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
> wrote:
> > This looks like a potential problem when possible passed methods are not
> > bound + it looks inconsistent with *"use strict"* expectations.
>
Yes. This looks like a typical s
Fair enough, I was looking for that part indeed but couldn't find anything
explicitly related in here:
http://www.w3.org/TR/2011/WD-html5-20110525/timers.html
Thanks!
On Sun, Sep 7, 2014 at 6:36 PM, Mathias Bynens wrote:
> On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
> wrote:
> > This loo
On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
wrote:
> This looks like a potential problem when possible passed methods are not
> bound + it looks inconsistent with *"use strict"* expectations.
It’s not just `setTimeout` – other DOM timer methods have the same
behavior. The spec is here, FWIW
I know this is probably W3C land but the following code shows the global
object in every JS engine I could test:
```js
(function () {
'use strict';
setTimeout(function () {
'use strict';
console.log(this);
// [window/global Object]
}, 0);
}());
```
This looks like a potential pr
52 matches
Mail list logo
