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).
Port a simplified version of Meteor.EnvironmentVariable and
Meteor.bindEnvironment to fiber-helpers.js to deal with this.
Identify uses of fiberHelpers.inFiber and switch them to either
fiberHelpers.bindEnvironment (if the callback they are wrapping is
semantically "part of" the context that creates the callback) or
fiberHelpers.inBareFiber (otherwise).
Without this, concurrency was causing the wrong buildmessage message
sets and jobs to be active when builds yielded.
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'.
