First exception: _runQuery didn't check to see if it was stopped after
running the query, which could lead to this harmless error:
Exception in defer callback: TypeError: Cannot call method 'clear' of null
at _.extend._publishNewResults (packages/mongo-livedata/oplog_observe_driver.js:749)
at _.extend._runQuery (packages/mongo-livedata/oplog_observe_driver.js:657)
at packages/mongo-livedata/oplog_observe_driver.js:615
at _.extend.withValue (packages/meteor/dynamics_nodejs.js:56)
at packages/meteor/timers.js:6
at runWithEnvironment (packages/meteor/dynamics_nodejs.js:108)
Second exception: _fetchModifiedDocuments thought that it should only be
in FETCHING in a certain case, but QUERYING is also OK. This is also
harmless since the correct behavior is to end the deferred routine.
Exception in defer callback: Error: phase in fetchModifiedDocuments: QUERYING
at packages/mongo-livedata/oplog_observe_driver.js:435
at packages/mongo-livedata/oplog_observe_driver.js:16
at _.extend.withValue (packages/meteor/dynamics_nodejs.js:56)
at packages/meteor/timers.js:6
at runWithEnvironment (packages/meteor/dynamics_nodejs.js:108)
If you call UI.renderWithData, say, from an event handler, you may be unpleasantly surprised if it gets Blaze.currentView as its parentView (where Blaze.currentView is based on the template where the event handler is defined). On the other hand, showdown/template-integration.js takes advantage of the fact that Blaze.toHTML in render() is infers the parentView from Blaze.currentView. So only infer currentView as parent while in the view’s render().
This change should only affect apps and packages that use Blaze.render, Blaze.toHTML, UI.render, or UI.renderWithData.
We've occasionally seen weird configurations of IE where localStorage
isn't shared between same-origin windows, so trying window.opener first
is safer.
Using an onerror event handler looks like the only semi-reliable way to
be able to close the popup in iOS Chrome, even though it's almost
certainly a bug that this works. We'll replace it soon with
redirect-based OAuth.
This reverts commit c05ae240af EXCEPT for
the "fetch in observe" test, which I'm leaving in because we still want
a test for #2275.
This commit made it an error to start an observeChanges from within an
observeChanges callback for the same collection, but it turns out that
this is actually a somewhat common thing to do (for example, nested
'each'). Instead, we'll leave things the way they were pre-0.8.2: you
can start an observeChanges from within an observeChanges callback, but
it'll be subtly buggy in that you won't get synchronous 'added'
callbacks. This issue is described in #2315, along with the fact that
insert/update/remove/resumeObservers won't run their affected observe
callbacks if they are called from within a task on the collection's
queue. Eventually we'll implement the full fix (which relaxes the
requirement that insert/update/remove run all their callbacks before
returning) described in #2315.
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”
Problem:
Static properties of the parent function ("class") were not copied to the child
function as expected. This is because the _.each underscore helper does not
propertly iterate over function properties.
Solution:
Don't use _.each to copy parent properties to the child function. Instead,
iterate directly and copy hasOwn properties to the child function.
An alternative solution is to make the _.each helper work properly with
functions in the underscore package.
