Last Comment Bug 388833 - Add a way to launch XUL applications from Firefox commandline
: Add a way to launch XUL applications from Firefox commandline
Status: RESOLVED FIXED
:
Product: Toolkit Graveyard
Classification: Graveyard
Component: XULRunner (show other bugs)
: Trunk
: x86 Windows XP
: -- normal with 1 vote (vote)
: ---
Assigned To: Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg]
:
Mentors:
Depends on: 389779 390046 428830
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-19 11:38 PDT by Mark Finkle (:mfinkle) (use needinfo?)
Modified: 2016-02-12 08:12 PST (History)
16 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
firefox.exe honors -app application.ini, rev. 1 (5.93 KB, patch)
2007-07-19 14:39 PDT, Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg]
ted: review+
Details | Diff | Splinter Review

Description Mark Finkle (:mfinkle) (use needinfo?) 2007-07-19 11:38:50 PDT
Now that Firefox is libxul based, we can launch XUL-based applications using its runtime. The launch code could be ported from XULRunner so Firefox could launch applications from its commandline, kind of like the -chrome commandline parameter.

For example,
firefox -app <path-to-application.ini>
Comment 1 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2007-07-19 14:39:22 PDT
Created attachment 273035 [details] [diff] [review]
firefox.exe honors -app application.ini, rev. 1

This kinda-sorta does what we want. firefox.exe can now accept -app <application.ini> to launch a XR app. There are of course still problems:

1) Firefox prefs and commandline handlers are still in effect.
2) On Mac the dock icon will be Firefox
3) On Windows the shared taskbar icon will have the Firefox logo.
Comment 2 Ted Mielczarek [:ted.mielczarek] 2007-07-25 13:15:06 PDT
Comment on attachment 273035 [details] [diff] [review]
firefox.exe honors -app application.ini, rev. 1

+ * A helper class which calls NS_LogTerm/NS_LogTerm in it's scope.

grammar-nit: should be "its"

+  else if (IsArg(argv[1], "app")) {

Err, shouldn't you check that argc > 1 here?

You may also want to note somewhere that -app *must* be the first parameter to firefox.exe, so people aren't confused when they try to stick -console or something in there first.

r=me otherwise.  I do think people are going to use this and then complain about the nits though.  :)
Comment 3 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2007-07-25 14:06:23 PDT
Fixed on trunk with nits and with a bustage-fix for GCC, which doesn't accept foo = value as an initializer for nsAutoPtr like MSVC does.
Comment 4 Serge Gautherie (:sgautherie) 2007-08-05 15:20:38 PDT
Comment on attachment 273035 [details] [diff] [review]
firefox.exe honors -app application.ini, rev. 1

>Index: browser/app/nsBrowserApp.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/browser/app/nsBrowserApp.cpp,v
>retrieving revision 1.45
>diff -u -8 -p -d -r1.45 nsBrowserApp.cpp
>--- browser/app/nsBrowserApp.cpp	11 Jul 2007 15:16:30 -0000	1.45
>+++ browser/app/nsBrowserApp.cpp	19 Jul 2007 21:13:19 -0000
>@@ -40,16 +40,20 @@
>+/**
>+ * A helper class which calls NS_LogTerm/NS_LogTerm in it's scope.

Shouldn't this be "NS_LogInit/NS_LogTerm" ?

>+ */
>+class ScopedLogging
>+{
>+public:
>+  ScopedLogging() { NS_LogInit(); }
>+  ~ScopedLogging() { NS_LogTerm(); }
Comment 5 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-08-05 16:49:35 PDT
(In reply to comment #4)
> Shouldn't this be "NS_LogInit/NS_LogTerm" ?

I fixed the comment (nsAppRunner.cpp/nsBrowserApp.cpp).

Note You need to log in before you can comment on or make changes to this bug.