The -remote option has existed essentially forever, but its usefulness is
questionable:
- It requires a running instance to be any useful, so any script actually
using it should first do -remote 'ping()' and handle the response properly.
- It is not cross-application. The remote service dispatches the -remote
commands to the command line handler, and, for example, desktop b2g builds
don't have handlers for -remote (although thunderbird and seamonkey do).
- It is not a cross-platform option, which leads to the following point:
- There are other command line ways to do the same thing (at least in
Firefox), without having to jump through hoops with -remote 'ping()',
because there are command line options to do those same things on non-X11
platforms.
For the latter, in Firefox case:
- -remote 'openURL(url)' can be replaced with firefox url
- -remote 'openURL(url,new-tab)' can be replaced with firefox -new-tab url
- -remote 'openURL(url,new-window)' can be replaced with firefox -new-window
url
- -remote 'openfile(file,...)' is the same as -remote 'openurl(file,...) so,
can be replaced as above
- -remote 'xfedocommand(openbrowser)' is inherited from the mozilla suite and
doesn't make much sense, but can be replaced with firefox -new-window
The interesting part is that without changing nsBrowserContentHandler.js,
-remote still works, meaning that if people really feel strongly about
-remote, they'll still be able to write an addon to bring it back. This also
means this patch actually doesn't remove -remote for applications other than
Firefox that do support it, although -remote 'ping()' doesn't work as
expected. However, other -remote commands will now work even without a
running instance.
With bug 1077366, the linker makes the library containing it a fake
LD_PRELOAD. As a consequence, instead of, in the linker itself,
explicitely special-casing the symbols that disappeared in Android 4.4
that the flash plugin uses, it is now possible to use normal symbol
resolution to stubs defined separately in libmozglue.
With bug 1077366, --enable-wrap-malloc is not abused anymore for android
linkage. Other than android linkage, the option has been of limited
usefulness since bug 804303 (replace-malloc), which allows runtime wrapping.
In fact, chances are --enable-wrap-malloc breaks things with jemalloc
integration.
This doesn't, however, remove those options from standalone js builds,
although it's not clear they're any useful there either.
Since essentially everything is linked to libmozglue and libmozglue takes
precedence in symbol resolution in our dynamic linker, there is no need
to wrap most symbols. PR_GetEnv/PR_SetEnv still needs wrapping because
there's no other way to actually wrap the calls from NSPR itself and NSS,
as well as the symbols wrapped because our dynamic linker can't find them
in system libraries on some devices because they're weak.