nsIAppStartup.quit(eRestart) with command line parameters
Jan Odvarko
extension's code is modified):
Cc["@mozilla.org/toolkit/app-startup;1"] .getService(Ci.nsIAppStartup)
.quit(Ci.nsIAppStartup.eRestart|Ci.nsIAppStartup.eAttemptQuit);
The problem is that the new Firefox instance doesn't use command line
parameters that were specified for the first run (e.g: -console -
chromebug etc.)
Does anybody have any tips how to solve this?
Thanks!
Honza
Benjamin Smedberg
> Firebug is using the following code to restart Firefox (when
> extension's code is modified):
>
> Cc["@mozilla.org/toolkit/app-startup;1"] .getService(Ci.nsIAppStartup)
>
> The problem is that the new Firefox instance doesn't use command line
> parameters that were specified for the first run (e.g: -console -
> chromebug etc.)
This is by design. The eRestart flag was designed for use by application
update or the extension manager update system: in those cases if you
originally launch the browser with a URL (such as if you open a URL from the
OS), you wouldn't want to open that same URL when you restart the application.
There are a couple bugs on being able to specify restart parameters
explicitly, but I've never seen a use-case good enough to warrant the
additional complexity that would be necessary.
--BDS
John J Barton
-chrome <chromeurl>
Without the command line value, the restart is incorrect.
-jsconsole
Without the command line value, the Error Console does not come back
-console
Without the command line value, the OS console does not come back
-no-remote
-p <profile-name>
-profile <profile-name>
All these fail if another firefox has run between the start and
restart of this one.
Ok I guess you get my point of view: I think its just an accident that
restart without command line values works. Most of the time the defaults
values work, which is to say that firefox generally does the right
thing without command line values. So the only time we need them is when
we use them ;-).
jjb
Dave Townsend
**SNIP**
> -p <profile-name>
> -profile <profile-name>
If the effect of these aren't persisting across a restart then a bug
needs to be filed, however I've never had that problem and I use -P all
the time. Firefox persists the location of the profile in use in an
environment variable so it is available to the spawned process.
Dave
John J Barton
Ok, great so why not the other command line parameters? I agree with
Ben that the URL seems to be exceptional.
jjb
Jan Odvarko
> additional complexity that would be necessary.
parameters:
firefox.exe -P dev103 -console -no-remote -chromebug -jsconsole
This causes to open:
0) Firefox browser window
1) System console window.
2) Chromebug window (debugger for chrome)
3) Error Console window
After I modify Firebug's code (chrome space), I want to restart
Firefox and have all the windows opened automatically for me.
The goal here is to have "one click" restart user experience so,
restarting Firefox after each modification isn't so big pain.
Currently when I do it, none of the mentioned windows is opened except
of the Firefox browser window itself (also note that Chromebug isn't
even initialized).
It would be much easier to develop. What do you think?
Honza
Benjamin Smedberg
> On Thu, Jun 11, 2009 at 12:48 PM, Benjamin
> Smedberg<benj...@smedbergs.us> wrote:
>> There are a couple bugs on being able to specify restart parameters
>> explicitly, but I've never seen a use-case good enough to warrant the
>> additional complexity that would be necessary.
>
> the "restart set" if they're not going to be meaningful in these
> scenarios. It would seem like the majority of the command-line args
> we take should be preserved, and that the URL or other transient ones
> are the exceptions.
I don't think that the current use-case is compelling enough to warrant the
additional complexity of actually implementing it in either the additive or
subtractive form.
--BDS
Benjamin Smedberg
> When I am fixing a bug in Firebug, I always run Firefox with following
> parameters:
>
> firefox.exe -P dev103 -console -no-remote -chromebug -jsconsole
...
> After I modify Firebug's code (chrome space), I want to restart
> Firefox and have all the windows opened automatically for me.
>
> The goal here is to have "one click" restart user experience so,
> restarting Firefox after each modification isn't so big pain.
I don't think that making one-click restarts is worth the added complexity
in command-line handlers and restart code, which is already fiendishly
complex. Quitting and using a shortcut file to relaunch would solve most of
your problems, I hope, and only involve two clicks or so.
--BDS
John J. Barton
Ok but for us an improvement of a factor of two-or-so is valuable. Is it
even possible to get the complete list of the command line parameters in
JS code so we can try to do something ourselves? By the time we get the
command line in our command line handler some parts have been removed.
jjb
Benjamin Smedberg
> Ok but for us an improvement of a factor of two-or-so is valuable. Is it
> even possible to get the complete list of the command line parameters in
> JS code so we can try to do something ourselves? By the time we get the
> command line in our command line handler some parts have been removed.
Could you be more specific? Because profile selection happens before XPCOM
launch, the profile-handling flags will have been removed (and saved) before
the command line is handled. All other flags should be present when handling
begins.
If you install an early handler you can see all the commandline arguments
before they start being removed by the handler chain: you can do this by
registering a category entry starting with "a", say, instead of the standard
"m":
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/commandlines/public/nsICommandLineHandler.idl#45
--BDS
John J. Barton
> On 6/15/09 9:25 AM, John J. Barton wrote:
>
>> Ok but for us an improvement of a factor of two-or-so is valuable. Is it
>> even possible to get the complete list of the command line parameters in
>> JS code so we can try to do something ourselves? By the time we get the
>> command line in our command line handler some parts have been removed.
>
> Could you be more specific? Because profile selection happens before XPCOM
> launch, the profile-handling flags will have been removed (and saved) before
> the command line is handled. All other flags should be present when handling
> begins.
If I run with:
-jsconsole -p chromebug1.5 -no-remote -chromebug -runFBTests
chrome://firebug/content/testList.html#dom/1738/1738.js
I see:
Chromebug Command Line Handler arguments on cmdLine: 4.0)-jsconsole
Chromebug Command Line Handler arguments on cmdLine: 4.1)-chromebug
Chromebug Command Line Handler arguments on cmdLine: 4.2)-runFBTests
Chromebug Command Line Handler arguments on cmdLine:
4.3)chrome://firebug/content/testList.html#dom/1738/1738.js
So the profile and no-remote are removed. Honza also says 'console' may
be removed. Maybe these are the only ones?
>
> If you install an early handler you can see all the commandline arguments
> before they start being removed by the handler chain: you can do this by
> registering a category entry starting with "a", say, instead of the standard
> "m":
> http://mxr.mozilla.org/mozilla-central/source/toolkit/components/commandlines/public/nsICommandLineHandler.idl#45
Yes, I register at "aaa-chromebug" now; was 'b-chromebug' recently.
jjb
Benjamin Smedberg
> So the profile and no-remote are removed. Honza also says 'console' may
> be removed. Maybe these are the only ones?
Yes.
--BDS