Fixes#13729
Previously, when adding a window, we were unable to read its current
project paths out of the hash of the URL during window initialization
because the window still considered itself to be loading. Rather than
fixing this issue, we decided to completely eliminate the sharing of
state between processes in the window.location and instead switch to
cached synchronous RPC for the loadSettings and a dedicated RPC-based
mechanism for the project paths.
Throttling in test windows is annoying when tests run interactively,
and *seems* to cause issues with animation frames not firing even in
headless tests, though it’s difficult to fully confirm since this issue
is intermittent.
This doesn't seem to work as expected. I think it's just better to encourage
emitting an event like 'write-to-stdout' or using directly `remote.process`.
/cc: @nathansobo
The idea with this commit is to implement a timeout functionality that does not
rely on a system utility (such as unix `timeout`). Tests could hang because of a
CPU-bound task and, as a result, we need to handle timeouts in a separate
process.
An ideal implementation would first spawn the timeout, which in turn would spawn
the tests, acting as a supervisor and making sure they do not exceed the
supplied time. However, setting up such an environment would have been trickier,
thus the test process spawns the timeout cop before running any test. This, in
turn, invokes a `setTimeout` function and kills the parent process as soon as
the timeout gets triggered, logging to console the reason why the parent process
was killed (and exiting the parent process with code 130).
I haven't used `Task` because, in order to log stuff to the console, we need to
fork the ChildProcess from `remote`, as otherwise nothing gets written out.
If the nearest containing package.json of a test path has an
atomTestRunner field, we’ll require the specified file as a test runner
rather than the default jasmine runner.
