1123574 - Invalid command-line options are ignored

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, defect)

Description

[Ulrich Windl]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 2014112600

Steps to reproduce:

This is a very annoying bug with a long tradition: If you specify an unknown command line option (like "firefox  -profile" instead of "firefox -ProfileManager"), Firefox simply starts without any complaint, but the options has no effect.
I wnat to run Firefox with some specific option, but my memory caused a misspelling of the option


Actual results:

Firefox simply ignores the invalid option.


Expected results:

Firefox should have complained, possibly listing the bad options plus a listing of all options available.
Note: Firefox also uses "long options" prefixed by a single minus ('-'), instead of following the GNU tradition of prefixing long options with double-minus ('--').

Comment 1

[:Gijs (he/him)]

The --syntax works, too. We can't easily remove the single-dash syntax because of backwards compatibility concerns, I think. :njn might know more (considering bug 1080302) about how easy it is to do the "invalid arguments should break stuff" implementation without breaking the world.

Comment 2

[Mike Hommey [:glandium]]

(In reply to Ulrich Windl from comment #0)
> User Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101
> Firefox/34.0
> Build ID: 2014112600
> 
> Steps to reproduce:
> 
> This is a very annoying bug with a long tradition: If you specify an unknown
> command line option (like "firefox  -profile" instead of "firefox
> -ProfileManager")

Note that -profile *is* a supported command line option, although it takes a parameter.

Not that it changes the reality of this bug.

Comment 3

[Nicholas Nethercote [inactive]]

As Gijs says, both -foo and --foo (and on Windows, /foo) options are accepted, and bug 1080302 changed the help messages to use the --foo form. But that bug didn't change any other functionality, so I can't provide any additional information about would break.

Given how old the "ignore unrecognized options" behaviour is, I suspect changing it could cause all sorts of obscure problems for people, and so the problems cause could well outweight the potential benefits :(

Comment 4

[Ulrich Windl]

On comment #3 (...so the problems cause could well outweight the potential benefits...): Considering that "firefox -whatever" triggers no message at all, fixing this bug may uncover lots of broken firefox invocations, but wouldn't it be a good thing?

Comment 5

[Ulrich Müller]

I was hit by this bug when trying to reproduce Gentoo bug <https://bugs.gentoo.org/542046>. The -remote option is gone from firefox 36.0, but it is still happily accepted (and ignored):

   $ firefox --version
   Mozilla Firefox 36.0
   $ firefox -remote "openURL(http://www.gentoo.org/,new-tab)"
   $ echo $?
   0

Please add some sane option parsing that displays an error message and exits with non-zero status if an invalid option is met.

Comment 6

[Edward Stauff]

I confirmed this in Firefox 46.0 running on Windows 7 Ultimate (6.1.7601) and on Windows 10 Pro (10.0.10586).  Could somebody please change the status from Unconfirmed to New?  (I don't have that permission.)

Comment 7

[Benjamin Smedberg]

We are not going to fix this bug. There are multiple layers of code that accept arguments, and by the time we've reached some of them we're well past startup. So we've decided to be lenient.

Comment 8

[Ulrich Windl]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #7)
> We are not going to fix this bug. There are multiple layers of code that
> accept arguments, and by the time we've reached some of them we're well past
> startup. So we've decided to be lenient.

Why not having a (more or less) global variable capturing "invalid arguments were found", and then pop up a dialog saying so ("invalid arguments were found") (if normal reporting seems to late). Clever programmers can do more clever things. I think Firefox has enough framework to allow for error reporting. The absolute minmum would be reporting to the error console.

Ignoring invalid command line parameters is only acceptable for embedded systems designed to run in 400 bytes of RAM ;-)

Comment 9

[Benjamin Smedberg]

Unrecognized flags should be reported to the browser error console already via http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserContentHandler.js#799

In the originally-reported case of -profile, you're using a real command-line flag so that wouldn't show up.