We had a bug in which event handlers inside {{#if}} blocks
didn't see the data context.
I'll commit a test that would have caught this after this commit.
Instead of `callWithNoYieldsAllowed` which calls a function
within (introducing a new stack frame that doesn't absolutely
nothing on the client), we now use `withNoYieldsAllowed` that
returns a new function that then gets called.
Since Deps is used all over the place, and in particular
in Blaze, this makes it much easier to look at the stack
trace when stopping in a debugger (for example, when a helper
gets re-executed).
Motivated by the Blaze manual.
It seems like a good practice for tests to always be grouped under their package name, so that it’s easy to find the tests when they fail. It’s confusing to have the tests in packages like “spacebars-tests”, “spacebars-compiler”, and “templating” be in various groups like “spacebars - templates” and “spacebars - templating”.
I didn’t go through and enforce this convention in all packages, just a few, but I think it would be good and not too hard to do the rest sometime.
stat fails if a symlink points to something nonexistent. since we're
literally looking for stuff physically under a directory, we don't need
to chase symlinks.
If you successfully subscribed to a publisher, changed user ID, and the
second time running the publisher it failed the audit-argument-checks
test, the error would say "Did not check() all arguments during
publisher 'undefined'" instead of including the correct publisher name.
That's because the "recreate Subscription on setUserId" code forgot to
include the sub's name in the new Subscription (the name field is
literally only used for this error message).
Alluded to in #2092
This is useful when the output tarball would just be unpacked immediately
anyway, e.g. because it is part of a larger build process. This shaves
eight seconds off my build. :)
Remove "Password is the plaintext password." comment from SRP Server. Likely a cut and paste error, as SRP server is never passed the plaintext password.
IE8 is 95% to blame, our code is 5% to blame for using the same
identifier twice in a scope (still not clear to me if that is
technically legal code), minification is 0% to blame even though
it revealed the issue :)
The minifier changed the two uses of HTMLTag into two different symbols:
var n = function r() {
var t = this instanceof e.Tag ? this : new r(), n = 0, o = arguments.length && arguments[0];
return o && "object" == typeof o && o.constructor === Object && (t.attrs = o, n++),
n < arguments.length && (t.children = Array.prototype.slice.call(arguments, n)),
t;
};
return n.prototype = new e.Tag(), n.prototype.constructor = n, n.prototype.tagName = t,
n;
Then, IE8 apparently actually creates two separate objects for 'n' and
'r'; see #3 at http://kiro.me/blog/nfe_dilemma.html
So just because n.prototype is an e.Tag doesn't make r.prototype a e.Tag
This means that `new r() instanceof e.Tag` is false, and so the first
line of the function leads to infinite recursion.
I'm not sure if this is an uglify bug as well; dealing well with
multiple declarations of the same function may be out of spec.
Fixes#2037.
The minifier changed the two uses of HTMLTag into two different symbols:
var n = function r() {
var t = this instanceof e.Tag ? this : new r(), n = 0, o = arguments.length && arguments[0];
return o && "object" == typeof o && o.constructor === Object && (t.attrs = o, n++),
n < arguments.length && (t.children = Array.prototype.slice.call(arguments, n)),
t;
};
return n.prototype = new e.Tag(), n.prototype.constructor = n, n.prototype.tagName = t,
n;
Then, IE8 apparently actually creates two separate objects for 'n' and
'r'; see #3 at http://kiro.me/blog/nfe_dilemma.html
So just because n.prototype is an e.Tag doesn't make r.prototype a e.Tag
This means that `new r() instanceof e.Tag` is false, and so the first
line of the function leads to infinite recursion.
I'm not sure if this is an uglify bug as well; dealing well with
multiple declarations of the same function may be out of spec.
Fixes#2037.
This reverts commit 32fc06e7f8.
As Glasser points out, our command option parsing is such that all `-a`
flags for commands have to be consistent in whether they are boolean or
not. Since we could easily imagine wanting a boolean `-a` or `-r` flag
in the future, we should be careful about adding these aliases. We'll
update the docs to remove `-a` and `-r` instead.
