We need to put a timestamp to nsRemoteService::HandleCommandLine() to allow Gtk+ focus
opened Firefox window.
Unfortunately we don't have much choice how to get the timestamp at DBUS remote service
so ask for gtk_get_current_event_time() and when GDK_CURRENT_TIME is returned
(it means we don't have the timestamp) use g_get_monotonic_time() as well
as at nsWindow::GetEventTimeStamp().
MozReview-Commit-ID: 9ilVZ0kPe3x
--HG--
extra : rebase_source : 457a6aedde4c45e2d7f168994c2a75d0336187c5
DBus strings can contain only [a-z][A-Z][0-9]_ chars. Encode profile name (used as part of interface name) by base64 and adjust it to avoid crashes (Bug 1418985).
Also remove DBusError where it's not useful.
MozReview-Commit-ID: DWnzFGUYybp
--HG--
extra : rebase_source : 1a7018d2cdde7c95f03c6ef3615b60e44ac6c813
It creates new nsRemoteService instance which is parent (proxy) class which is registered as global nsIRemoteService. It provides basic functionality (watch observer for shutdown, launch firefox instance by HandleCommandLine()) for child services which are system specific. nsDBusRemoteService listens on DBus interface and it's available on DBus enabled systems only. nsGtkRemoteService is the former one based on X window propery mechanism.
MozReview-Commit-ID: GHpXdjstwyY
--HG--
extra : rebase_source : 54847a04ebd0bae6dc3d33352e8155a1e3fa09f4
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Because bug 1282866 removed Qt support but missed a bunch of things.
* * *
Bug 1285554 - more
--HG--
extra : rebase_source : c48d2485f1fdf1c961e08d91651bbca41e3a1a53
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
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.