A new configure option --with-devtools (which sets MOZ_DEVTOOLS) is added to
control whether all DevTools, just the server, or no DevTools are included.
This defaults to just the server.
Applications should also include /devtools within their moz.build tree, so that
DIST_SUBDIR is in effect for all DevTools files if it is used by the app.
To enable resource://devtools, all DevTools files are consolidated at the app
level. This means they are no longer available for sharing between multiple XUL
apps, such as browser and webapprt. We'll need to devise a new method to bring
this support back to webapprt if desired.
The configure option has explicitly thrown an error for more than a year now,
and it happens that the remaining way to still forcefully use it has been
broken for more than 8 months.
In bug 922912, we folded back gkmedias.dll info xul.dll, so in practice, there
is no default configuration left that exercises GKMEDIAS_SHARED_LIBRARY. And
sure enough, it's been broken for months in many different ways.
The gkmedias intermediate library is however kept for webrtc signaling tests.
Break DevTools content files out of browser.jar and move to a new DevTools
specific jar. Update all paths of the form:
chrome://browser/content/devtools/<X>
to
chrome://devtools/content/<Y>
where <Y> is the source tree path that comes after /devtools/client.
--HG--
extra : commitid : FuxFbzraUST
extra : rebase_source : f9ebe14ee60119881fa110ab0cc21f5f6f7930ef
The current situation looks like this: Firefox launches the plugin-container
with two environment variables set:
LD_LIBRARY_PATH=$FIREFOX_DIR:$LD_LIBRARY_PATH
LD_PRELOAD=$FIREFOX_DIR/libmozgtk2.so:$LD_PRELOAD
libxul.so has a dependency on libmozgtk.so (without "2"), but libmozgtk2.so
has a SONAME of libmozgtk.so, so ld.so recognizes libmozgtk2.so as a
dependency of libxul.so, and uses it instead of the actual libmozgtk.so,
making the plugin-container use Gtk+2 instead of Gtk+3 to load Gtk+2 plugins.
Now, ASan sets things up in shared libraries such that they needs a symbol
from the executable binary. So in the case of plugin-container, the
plugin-container executable itself contains some ASan symbols such as
__asan_init_v3. libmozgtk2.so, OTOH, contains an undefined weak reference to
that symbol, like all other Firefox shared libraries.
Since libmozgtk2.so is LD_PRELOADed, it is loaded _before_ the
plugin-container executable, and __asan_init_v3 can't be resolved.
Disabling ASan for libmozgtk2.so would be a possibility, but the build system
doesn't really know how to do that, and filtering out -fsanitize=address
can be fragile.
The alternative possibility, implemented here, is to change the library
loading strategy, renaming libmozgtk2.so to gtk2/libmozgtk.so, and setting
the following environment variable when Firefox launches the plugin-container:
LD_LIBRARY_PATH=$FIREFOX_DIR/gtk2:$FIREFOX_DIR:$LD_LIBRARY_PATH
Refactoring to allow access to PushManager in ServiceWorkerGlobalScope. See comment in PushManager.h for details.
--HG--
extra : commitid : A7RvB9rm8av
extra : transplant_source : %20%99%CA%B0%EB%B9%82%27D%F7e%B8UQ%12%E6%9B%18%BB5
packager.py itself has been able to do preprocessing since the beginning.
For some reason, Makefile.in-driven preprocessing was kept back then, and
never was removed, and even worse, concatenation was added on top of it.
There is however a downside to the current way of doing things: error
reporting is given relative to the given manifest, which in the current
case is the preprocessed/concatenated file, so line numbers don't match
what is in the file in the source tree. However, when packager.py does
preprocessing itself, line numbers are reported properly.
Thus, switch all package manifests to packager.py-driven preprocessing.
