Before making top-level traverse js/src moz.build files, there was a need to
distinguish between top-level traversing e.g. top-level moz.build or
config/moz.build and js/src traversing them. With a single traversal of both
moz.build sets, we now only need to distinguish between js standalone builds
and gecko builds.
There is still, however, a need to distinguish between top-level vs. js/src
configure runs on gecko builds to make them subconfigure icu and libffi from
top-level instead of js/src in js standalone builds, or when choosing to make
js/src's config.status do something when run or not.
Before, we would run configure in both top-level and js/src, and both
configures would traverse their own set of moz.builds, without actual
knowledge about the other. With this change, both configures still run,
but only top-level traverses moz.build files, and uses js/src's
config.status when traversing its moz.build files. This allows a better
sharing of information between both build systems and the removal of many
hacks.
This also moves running libffi and icu configure to top-level.
Standalone js builds still have their own configure doing moz.build traversal,
as before.
--HG--
rename : config/autoconf.mk.in => config/autoconf-js.mk.in
rename : config/emptyvars.mk.in => config/emptyvars-js.mk.in
We happen to be lucky currently because e.g. build is created by config.status
before we subconfigure in build/clang-plugin. But further changes break that
luck.
A non-realtime graph does not start up again after finished processing, so it
can safely enter LIFECYCLE_WAITING_FOR_STREAM_DESTRUCTION.
--HG--
extra : transplant_source : %AF%98D%D5%EE%CA7zfv.%B4%F4%D8%05Q7%C2%8D%A7
As a side-effect, the buffer playback will now continue from the same buffer
sample number (even when looping), where possible, in the following situations:
* Changing the loop start or end parameters.
* Changing the buffer to one of a different sample rate.
--HG--
extra : transplant_source : 2%11%7Dm%92pu%60%E3G%D4%D4%DB0%2B%20%9A%1Bd%FA
The platformName capability (which AFAICT isn't checked in use by any
dependants) should be a limited subset of prescribed platforms as
defined by the WebDriver specification. System.appinfo.OS returns the
correct values, but not upper cased.
Additionally this patch introduces some tests and documentation for
the getSessionCapabilities function in Marionette and cleans up the
capability list.
Support for main process crashes, plugin crashes, and plugin hangs is
added to the crash manager. This includes a JS API for reporting them as
well as support for reading the event files.
There is still an issue of unbound growth on the store. This will be
addressed in a subsequent patch.
--HG--
extra : rebase_source : e714bf5f9c2fd9c50f2e40659c3b1a89591f3b1a