If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

commandline URL ignored in combination with certain arguments



Core Graveyard
Cmd-line Features
17 years ago
9 years ago


(Reporter: tenthumbs, Unassigned)


Firefox Tracking Flags

(Not tracked)



(1 obsolete attachment)



17 years ago
While testing something else, I discovered that
  ./mozilla URL
works as expected but
  ./mozilla --no_xshm URL
always displays the default home page.

I suspect that command-line parsing is screwed up somewhere.

Comment 1

17 years ago
Assignee: asa → law
Component: Browser-General → XP Apps: Cmd-line Features
QA Contact: doronr → sairuh
Assignee: law → mcafee
am also seeing this using 2001.04.02.08 comm bits on linux.

Comment 4

17 years ago
over to blizzard for a look, timeless?  someone was working on this,
I forget.
Assignee: mcafee → blizzard
Summary: Command line arg processing error → Linux: Command line arg --no_xshm ignored
I wasn't.

Comment 6

17 years ago
Someone changed the summary without testing the problem. The --no-xshm arg
always works. It the args that follow that don't. I suspect any gtk arg will do
the same. I'm also guessing that gtk_init diddles the argv array in a way
mozilla doesn't understand.

Reverting the summary to the original.
Summary: Linux: Command line arg --no_xshm ignored → Linux: Command line arg processing error
The -server and -splash options also don't work ...

Mozilla/5.0 (X11; U; Linux 2.4.2 i586; en-US; rv:0.9+) Gecko/20010601, build

Comment 8

16 years ago
With mozilla 0.9.4 on RH 7.1, the following problem exists:

mozilla http://www.mozilla.org works


mozilla -chrome chrome://navigator/content/navigator.xul http://www.mozilla.org
just shows a blank page.

We use custom chrome and with this bug, we cannot start mozilla with the
custom chrome and open a url simultaneously. Will this bug be addressed any time
soon? Mozilla 0.8 works fine. I haven't tested with other versions in between.

Comment 9

16 years ago
*** Bug 134388 has been marked as a duplicate of this bug. ***

Comment 10

16 years ago
*** Bug 109765 has been marked as a duplicate of this bug. ***

Comment 11

16 years ago
the problem is that when the next-to-the-last argument starts with a dash
(-splash, --no-xshm, --display=____, etc...) and the last argument does not, the
command-line parser assumes that the last argument is the value associated with
the next-to-the-last argument.  The commandline parser doesn't know which
arguments take values, so it has to assume the last argument is a value to
prevent stuff like

mozilla -P profilename

trying to make "profilename" into a URL.

the code used to handle this used to be there, but is commented out.


156         if (i == (aArgc-1)) {
157          /* This is the last argument and a URL 
158             * Append a PR_TRUE for the previous option in the value array
159             */
160            //mArgValueList.AppendElement((void *)PL_strdup("1"));
161            //mArgCount++;
163            // Append the url to the arrays
164            //mArgList.AppendElement((void *)PL_strdup("-url"));
165            mArgValueList.AppendElement(ProcessURLArg(aArgv[i]));
166            mArgCount++;
167            continue;
168         }

the only way I can think to fix this is to have a list of no-value arguments to
check against here.  If this would be a valid solution, lemme know, and I'll
whip up a patch.
Summary: Linux: Command line arg processing error → commandline URL ignored in combination with certain arguments

Comment 12

15 years ago
*** Bug 168640 has been marked as a duplicate of this bug. ***

Comment 13

15 years ago
I'm upping this to major.

Given that

mozilla http://www.yahoo.com -parameterthatdoesnttakeanything 

doesn't work (invalid syntax)


mozilla -parameterthatdoesnttakeanything http://www.yahoo.com

doesn't work

I think we have a major issue here, and definitely a regression from 4.x

The flaw here is the entire implementation of command line service. You can't
have a generic command line service by definition.

It needs some understanding of what the command line parameters are.
Severity: normal → major
Keywords: 4xp
OS: Linux → All
Hardware: PC → All

Comment 14

15 years ago
*** Bug 155210 has been marked as a duplicate of this bug. ***

Comment 15

15 years ago
this is a workaround
mozilla -parameterthatdoesnttakeanything dummyargument url
mozilla -quiet xx http://www.yahoo.com

Comment 16

15 years ago
better workaround: specify "-url" explicitly
mozilla -quiet -url http://foobar.com

see bug 155210.  some arguments that shouldn't take values will try to do
something with it if you specify one.

Comment 17

15 years ago
*** Bug 176164 has been marked as a duplicate of this bug. ***
Blocks: 40481

Comment 18

15 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

also command line arguments are just discarded if there is already a running
instance (on Windows, on Linux it works as expected).
   mozilla -P profile1 -mail
will show mailbox of profile1,
but the next
   mozilla -P profile2 -mail
just show another mail window of profile1. This makes it impossible to have to
different profiles open at the same time.

Comment 19

15 years ago
Alex: that is a different bug

Comment 20

15 years ago
It seemed to be alike. I filed the bug separately:

Comment 21

14 years ago
*** Bug 211526 has been marked as a duplicate of this bug. ***
*** Bug 225812 has been marked as a duplicate of this bug. ***


14 years ago
No longer blocks: 40481

Comment 23

14 years ago
*** Bug 40481 has been marked as a duplicate of this bug. ***
A variation of this bug is that you get a crash if the last argument is one that
is treated by GTK.

For instance, ./mozilla --display=:0.0 segfaults

The explanation is that gtk_init removes the arguments it treated and thus
updates argc and argv. But nsCmdLineService::Initialize gets a value that has
been saved _before_ the update.

Saving argc again after gtk_init call fixes the issue.

Fix for firefox will follow.

Note that #183640 is more than probably the same problem in an other bunch of
code (the viewer seems outdated, though)

Please change summary and severity to address the crash.
Created attachment 163578 [details] [diff] [review]
"not this bug"

Comment 26

13 years ago
> For instance, ./mozilla --display=:0.0 segfaults

No, it doesn't.  Firefox certainly does, but not mozilla.  Either way, it's not
this bug.  Please file a new one (and cc me -- thanks for making the patch).
Comment on attachment 163578 [details] [diff] [review]
"not this bug"

Not this bug
Attachment #163578 - Attachment is obsolete: true
Note to self: read more closely, even (especially?) if the description really
looks like a variation of my bug.

Sorry for the noise.

Comment 29

13 years ago
*** Bug 275434 has been marked as a duplicate of this bug. ***


13 years ago
Attachment #163578 - Attachment description: Fix → "not this bug"

Comment 30

12 years ago
*** Bug 319772 has been marked as a duplicate of this bug. ***
Assignee: blizzard → nobody
QA Contact: bugzilla → cmd-line

Comment 31

9 years ago
I can't quite tell what this bug is all about, it seems to morph all over the place. But our commandline handling is now uniform and pretty good, so I'm going to call this WFM and hope that any future issues are filed in the Toolkit:Startup and Profile component.
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME


9 years ago
Component: Cmd-line Features → Cmd-line Features
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.