Hopefully this isn't ignoring real error cases. The whole
previousSolution data-rewriting hack probably needs to be fixed
anyway. But this seems to work?
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.
In modifying getContent, we neglected the fact that parseAttrs wraps arrays in HTML.Attrs. Now we wrap arrays outside of parseAttrs near the code that modifies the attributes array for textarea contents.
Needs tests
Otherwise the DDP call to tinytest/run was blocking client test execution,
in particular Accounts DDP calls won't run concurrently with another DDP call,
even if the first DDP call calls unblock.
The template compiler assumes that single-segment paths like {{foo}}, compiled into view.lookup(“foo”), don’t take dependencies, returning a function if there is anything reactive going on. We violated that in the Blaze refactor, meaning that #with might re-render its contents when its argument changes!
Tests to add:
* UI.dynamic doesn’t re-create template when enclosing data context changes.
* UI.dynamic doesn’t re-create template when “data” argument changes
* Coverage for the “..” and “foo” cases in lookup.js
Tests to fix: “simple helper”
