In the old code, if you queued a task, did something which flushes the
queue (runTask, flush, or drain), and then queued another task, you'd
end up with two pending timeouts, rather than zero. With this change,
we're careful to never have two pending timeouts, and also to clear the
timeout if we're about to run all current tasks.
Regression introduced by the CSS watching code (specifically, f230eba62)
by the sourceIsWatched check. We need to be able to tell the difference
between "source handler didn't do anything because there was an error"
and "source handler didn't do anything because it's web-specific and
this is an os arch".
A simple fix would have been to interpret compileStep.error as
"sourceIsWatched = true", but I didn't think of that until after doing
it the slightly more complicated but more precise way :)
Also, ensure that if the runner rebuilds the client and there's an
error, it properly kills the app process (and the watchers and the
keepalive interval, etc).
It seems that when ObserveSequence observed a Cursor, it used to stop() the observe when the main autorun was invalidated, creating a “gap” during which no callbacks would be received (or fired). This was before we used Deps.nonreactive in the main autorun (shielding the cursor.observe from being stopped). Now the observe is only stopped upon re-run or when the ObserveSequence is stopped, and there is no gap.
Removed references to this gap from comments.
I believe the current code is correct, and in addition, we could now optimize the cursor-to-same-cursor case (and basically not do anything if seq===lastSeq and is a Cursor, i.e. not stop the old handle, create a new handle, or diff).
Until I made this I always got only ```<head/>``` with it's content, ```<body>``` was empty.
It seems setInterval script was finished earlier then url content was loaded to the page. Maybe because I have subscriptions with response time lower then 100ms so they were ready very quickly — database server in the same data center.
http://phantomjs.org/api/webpage/method/open.html
This was originally introduced with
f1b77fec96, but it looks
like all of our tests now pass. (Maybe eliminating `rewind` in
b5a0613f85 made this no
longer necessary?)
If we find that this commit did break something, let's make sure to
add a failing test before reverting.
Cordova projects often have a different set of files than web targets,
so we would like to be able to target different client architectures in
our bundles. Ideally, we allow the user to use arbitrary client
architectures - but this patch is a step in the right direction by
abstracting out more of the hard coded "browser"/"os" lines.
We accomplish this separation in a backwards compatible way by allowing
api.___ commands to target a "client" architecture. For example,
api.addFiles('a.js', 'client') adds 'a.js' to both the 'client.browser'
and 'client.cordova' targets.
Effects on 0.9 packaging stuff: packages don't have to change, but the
"data.json" file in ".meteor0" has "browser" in some places. We think we
have to fix the troposphere code where this data.json is created.
Some plugins will also be backwards-incompatible with this change, since
many have a "clientArch.matches("browser")" line in the plugin
code. Ideally, we fix plugins so that this stops being an issue, but for
now package authors can just patch that line.
At the compiled (unipackage) level the new names are 'web.browser' and
'web.cordova', replacing 'browser'. In package.js, the new names are
'client.browser' and 'client.cordova', serving as an adjunct to 'client'.
This reverts commit abbf3c78fa.
Something probably got weird switching between the 'packaging' branch
and 'devel'; mongodb and bson are forked on packaging, but we didn't
intend to be using a normal mongodb release with a forked bson.
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)
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.
