Steps to reproduce: 1. Launch Firefox by clicking its dock icon. Result: Error: Warning: unrecognized command line flag -foreground Source File: Minefield%202007-01-31.app/Contents/MacOS/components/nsBrowserContentHandler.js Line: 643

Bug 369147 – "Warning: unrecognized command line flag -foreground" on launch Whilst the Finder and/or the Dock do add command-line switches to the executables as they are launched, exempli gratia: http://www.cocoabuilder.com/archive/message/cocoa/2005/4/11/132904 http://seriss.com/people/erco/fltk/ http://lists.apple.com/archives/Java-dev/2004/Jul/msg00716.html I cannot find discussion about any switch other than the well-known -psn_xxx, and I would question whether this is the Mac runtime's doing. Is there any possibility that this argument is added during the 'Launch Children' phase of start-up? "foreground" is one of those words that is quite difficult to search on in Google and I can't be sure. It could be a forme fruste of some incantation intended to request X or Gtk to initialise to a known set-up. I attach a patch which should remove the output, but I wonder whether it would be better to live with it until we know what it means.

I'd also like to request that arguments starting with "-psn_" get ignored on Mac OS X systems. For users who run the Console utility, it can be annoying. The warning message causes the Console to bounce its Dock icon or raise the log window, depending on the settings. The -psn_XXX argument is added by the Finder/Dock during application launch. I can't find a definitive reference to the command line argument, but this include file discusses the process serial number. It is used by the Carbon APIs to identify other processes, usually to indicate the sender or receiver of an AppleEvent interprocess communication message. From /System/Library/Frameworks/ApplicationServices.framework/Frameworks/HIServices.framework/Headers/Processes.h: * [Mac]GetCurrentProcess() * * Discussion: * Return the canonical process serial number to the caller. * * All applications ( things which can appear in the Dock or which * are not documents and are launched by the Finder or Dock ) on Mac * OS 10 have a unique process serial number. This number is created * when the application launches, and remains until the application * quits. Other system services, like AppleEvents, use the * ProcessSerialNumber to specify an application.

I already fixed the -psn argument warning, at least on trunk. It might be fixed in FF 2.

Thanks for the comments. I actually saw this issue in Thunderbird 2.0. Will your change affect that package eventually or should I report it separately?

-psn is bug 304755. The fix was in toolkit so my guess is it's fixed for Thunderbird too. Test Thunderbird trunk if you want to be sure.

Since the -foreground should be removed by http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/xre/nsAppRunner.cpp&rev=1.203&mark=2683#2683 are we stacking up a pair of them, by adding one in nsCommandLineServiceMac when there's already one there?

I still see this in the first launch (fresh profile) in the latest Mac Minefield: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008020304 Minefield/3.0b3pre "Error: Warning: unrecognized command line flag -foreground Source File: file:///Users/jbecerra/Desktop/fx/Minefield.app/Contents/MacOS/components/nsBrowserContentHandler.js Line: 660"

This doesn't only appear for the first launch. It is shown on each start of Firefox. Could this be solved for Firefox 3?

Certainly not a blocker. I would take a well-tested patch. I'd want an answer to comment 6.

minusing per comment 9.

(In reply to comment #12) > *** Bug 459562 has been marked as a duplicate of this bug. *** OK sorry, I doesn't find this bug because I searched bugzilla only for Thunderbird bugs. I have this issue for Thunderbird. This patch is for the file /browser/components/nsBrowserContentHandler.js, which is not used for Thunderbird. So, which file is the equal one for Thunderbird?

http://mxr.mozilla.org/comm-central/search?string=nsicommandlinehandler&find=%2Fmail%2F (not that it matters, since a per-app patch to wallpaper the way nsAppRunner is letting its hack leak out is the wrong fix). I suspect that the problem comes in http://hg.mozilla.org/mozilla-central/annotate/ee5135f3f773/toolkit/xre/nsAppRunner.cpp#l3226 where as the comment says, we know we're not restarting, but we still go into nsMacCommandLine::SetupCommandLine's "Adding this argument is harmless if not relaunching" which causes just this harm. However, since I'm not currently in the state where you get the unrecognized -foreground, and don't know how to get into that state, I can't test the obvious patch of throwing a CheckArg("foreground") afer that SetupMacCommandLine call.

(In reply to comment #14) > I can't test the obvious patch of throwing a > CheckArg("foreground") afer that SetupMacCommandLine call. OK, I would try this, but I'm not so adepted in programming. I've tried it for my own, but my trials break the code (*whee*). In which way must I change the code in nsAppRunner.cpp#l3226 to test your suspicion?

That's interesting. Running a "ps -ef | grep Minefield" returns following result: 501 1862 1 0 0:21.15 ?? 1:33.06 /Applications/Minefield.app/Contents/MacOS/firefox-bin -foreground -foreground Means the foreground flag is passed twice to the application, which should not happen. So what's the status of the attached patch? It's a bit old and probably bit-rotted.

(In reply to comment #16) > That's interesting. Running a "ps -ef | grep Minefield" returns following > result: > > 501 1862 1 0 0:21.15 ?? 1:33.06 > /Applications/Minefield.app/Contents/MacOS/firefox-bin -foreground -foreground > > Means the foreground flag is passed twice to the application, which should not > happen. That isn't what I see, but then I can't reproduce the warning message. How are you reproducing this? > So what's the status of the attached patch? It's a bit old and probably > bit-rotted. Possibly, but it also seems to be the wrong place to tackle this though. Likely we'd want to strip it out from the command line earlier so it happens for all toolkit apps.

(In reply to comment #17) > That isn't what I see, but then I can't reproduce the warning message. How are > you reproducing this? I just opened the dmg image of a Minefield build, copied the application to /Applications and started it via Quicksilver. As what I can see now it also happens when calling it directly from within the Finder. And the amount of arguments varies between two and three: 501 2429 1 0 0:00.63 ?? 0:02.44 /Applications/Minefield.app/Contents/MacOS/firefox-bin -foreground -foreground -foreground

(In reply to comment #18) > (In reply to comment #17) > > That isn't what I see, but then I can't reproduce the warning message. How are > > you reproducing this? > > I just opened the dmg image of a Minefield build, copied the application to > /Applications and started it via Quicksilver. As what I can see now it also > happens when calling it directly from within the Finder. And the amount of > arguments varies between two and three: > > 501 2429 1 0 0:00.63 ?? 0:02.44 > /Applications/Minefield.app/Contents/MacOS/firefox-bin -foreground -foreground > -foreground And if you exit and run it a second time what do you see?

The argument is always visible. I've no idea how I should start to check why the Finder is using this argument.

Still happening on Firefox 3.6 - we're sure this isn't having a performance or other effect, right? Ben: can we get an answer to comment 6? That way we can get a patch reviewed and landed.

I have no explanation for what Henrik is reporting (is it a clean profile?); I don't believe Finder ever passes -foreground to us (although a few scripts running Firefox from the command line do). Phil's comments (comment 14 in particular) are correct though and should be fixed. (Note that since this spaghetti code manages to call SetupMacCommandLine() several times when restarting, we can end up launching a child process with several copies of the -foreground flag, only one of which would be processed, causing the other copy log a warning to the Error Console. Since this only happens on restart, I think trying to fix that is not worth the risk of breaking something else.)

(BTW this -foreground flag was added to the tree in bug 345057, which doesn't mention any meaning assigned to it by the system either). And I did do basic testing on 10.5 - running from finder, from the command line with/without the app auto-restarting and it appears to work fine. For me the -foreground error is easily reproduced by simply opening the app from finder (or, even easier, running with -foreground from the command line).

(In reply to comment #23) > I have no explanation for what Henrik is reporting (is it a clean profile?); I > don't believe Finder ever passes -foreground to us (although a few scripts > running Firefox from the command line do). I start all my applications via Quicksilver. Nothing is placed onto the dock and I also don't open Finder windows to start any of my apps. I can see that -foreground is passed at least twice to all of my running Firefox/Namoroka/Minefield processes. Those are all different profiles and I do not think that this is related to any pref changes.

Comment on attachment 437713 [details] [diff] [review] patch I'll delegate this to josh

http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#2973 "// Add the -override argument back (it is removed automatically be CheckArg) if there is one" Please fix the spelling error here (be -> by), might as well do it with this patch though it is unrelated.

Comment on attachment 437713 [details] [diff] [review] patch Please correct me if I'm wrong bug here is my understanding of what is going on... When the app starts, in XRE_Main, we call 'CheckArg("foreground")', which will check for the foreground flag, removing it if it exists. The problem is that it'll only remove one instance of the "foreground" flag and if there are two, the browser command line handler will treat the second one as an unrecognized argument. This patch attempts to solve the problem by not adding "foreground" when we're not going to restart - because if we're not going to restart, then XRE_Main will not run before the browser command line handler runs, which means XRE_Main won't remove "-foreground" and the browser handler won't recognize it. Assuming my understanding is correct I'm fine with this, though I wish we had a better general solution for this mac command line handler business.

BTW - I'll take a look at general improvements to the mac command line service when I get back to bug 542936. Thanks for the patch.

Josh: not exactly. Your analysis is correct up to 'The problem is that it'll only remove one instance of the "foreground" flag' - while that's a problem, it's a rare one and my change doesn't prevent the message in that case. The code basically goes like this: 1) handle and remove -foreground flag 2) if restarting, check if we're in foreground. If we are, add "-foreground" to the list of params to restart with. Restart (the child will handle the flag in (1)). 3) if not restarting, check if we're in foreground. If we are, add "-foreground" to the list of params we'll pass to command line handlers (even though we just removed it and even though command line handlers don't know anything about this param). Then start the app. It's the (3) I'm fixing - even if we're in foreground, we shouldn't pass "-foreground" to the command line handlers; this flag is only ever handled in (1) and we won't get there if we're not restarting. Please comment if you still approve of this change.

Yup, sounds good.

This got into the 20100417 mozilla-central nightly. I wonder, how this works for you now, Henrik. I filed bug 560043 for the remaining problem mentioned in comment 23.

(In reply to comment #34) > This got into the 20100417 mozilla-central nightly. I wonder, how this works > for you now, Henrik. No change for me with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a5pre) Gecko/20100418 Minefield/3.7a5pre. I still see three -foreground options included in the process output. Starting Minefield via Spotlight I get only two instances. Looks like I should file it as a new bug.

It's not fixed to me. It's still happening on FF3.6.13 on OS X 10.5.8!

That's because the patch hasn't landed on the Firefox 3.6 branch.

Mozilla Firefox v55.0a1 Win64 nightly from a couple days ago, this still exists. This has existed for several years, as I've noticed jpm and web-ext generated this error during add-on development. I just looked at version 3.5b4 and 4.0.1 on Windows, and this warning existed then. I suspect the patch was never applied. MDN still documents -foreground as a valid command line option, but it was apparently broken for over a decade, and even when supposedly patched, fixed and resolved, it never has been applied. Am I missing something here? Either fix the flag so it's recognized, or if nobody has cared enough to complained in over a decade, then maybe it's not needed, so just remove all references from add-on development tools and update documentation. web-ext and MDN specific bugs filed separately. If anyone knows the last version of Firefox on Windows when this flag worked (if ever), I can put a note on the MDN site to make that more clear.