Send them only on 'run' (which is likely to be running for a long time,
giving us plenty of time to send stats) and 'deploy' (which has to go
over the network anyway), though we don't wait for stats to be sent
before exiting from any commands.
Update stats self-test to run apps instead of bundling them. Add an
environment variable to print some output about when package stats have
been sent for the test to know when it's okay to stop the 'meteor run'
process.
presumably this was previously tested on a checkout where
tools/tests/apps/hot-code-push-test/client existed, but git doesn't know
how to check in empty directories. (another alternative would be to
check in a dummy file in that directory)
{{#each todos}} rendering was broken when no list was selected, since {{#each}} cannot iterate on "{}" (it only takes lists and falsey values).
This code path is never hit in the todos app as it is shipped, but it can cause problems with people modifying the example code for their own apps.
Programming errors like "the code doesn't try to provide a password"
should throw, but user errors like "the code pulled a password from an
input but it was empty" should use the callback.
Fixes#2272.
Instead of making _exactTransitiveConstraints smarter, I realized it was
only used as a single step in the appropriately smart
_propagateExactTransDeps. By replacing the transitive single steps
inside _propagateExactTransDeps with non-transitive single steps, the
code got simpler and didn't require the steps to themselves watch out
for infinite recursion.
Also, change newExactConstraintsList calculation to better match the
comment above it.
We were violating the contract "buffer is never empty in STEADY phase
unless everything matching fits into published", which is maintained by
_removeBuffered, by moving something from _unpublishedBuffer without
going through _removeBuffered.
Specifically, if we had already set _safeAppendToBuffer to
false (because we knew of some matching document below buffer) and did a
modification to a document in buffer, we could leave buffer empty
without triggering a repoll.
Fixes#2274.
Make some instances of #2315 into errors instead of silent early
returns.
Specifically, observeChanges calls (with added or addedBefore callbacks)
from within another observeChanges callback on the same collection will
be unable to differentiate between initial and later added/addedBefore
calls, which is serious enough to be an error (see #2315 for details).
We don't currently think that the other effect of #2315 (where observe
callbacks triggered by insert/remove/update/resumeObservers will not
occur before those methods return, if they are called reentrantly) is
problematic enough to deserve this sort of error.
Make sure inclusions with one path segment like “..” and “foo” (where foo is in the data context) don’t cause the enclosing template to re-render when the data context changes.
Don’t log them for stub streams.
In livedata_connection, fire the onConnected callback *after* we have set up the stream, so we don’t set up a stream that has just been disconnected!
Make sure we always call the `expect` function, even if we fail. That
gives us a nice failure message instead of "Async batch timed out".
Make sure we close the stream in each test if we fail. Previously, in
some IEs, a "basic disconnect" timeout without closing the stream seems
to cause a somewhat random subset of other tests to time out or
fail. (Possibly a per-domain connection limit?)
Using parentElement instead of parentNode was probably a typo. I didn’t even know there was an Element#parentElement alongside Node#parentNode in the DOM, but apparently there is, and apparently IE 9 supports it, but for some reason it doesn’t work.
The lesson is: never use parentElement on a DOM node. Use parentNode and be done with it.
Fix the “simpler helper” test and expand the cases where we detect that “foo” is missing or not a function (e.g. is a scalar property of the data context).
IE8 sets an element's `parentNode` to an HTMLDocument at funny times
even when the element hasn't been added to the DOM (like if you add a
child to the element), so a check for falsey sometimes misleads us into
thinking that the element is in the DOM when it's not (and thus calling
a moveElement UI hook for an element that was never inserted).
The corresponding check on `removeElementWithHooks` is okay, because if
the element's parentNode is an HTMLDocument, we won't find a ui hook to
call (unless you for some reason added ui hooks to the HTMLDocument).
Fixes "ui hooks" test in IE8.
