Closed
Bug 74303
Opened 23 years ago
Closed 15 years ago
commandline URL ignored in combination with certain arguments
Categories
(Core Graveyard :: Cmd-line Features, defect)
Core Graveyard
Cmd-line Features
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: tenthumbs, Unassigned)
References
Details
Attachments
(1 obsolete file)
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.
:(
Assignee: asa → law
Component: Browser-General → XP Apps: Cmd-line Features
QA Contact: doronr → sairuh
Updated•23 years ago
|
Assignee: law → mcafee
Comment 2•23 years ago
|
||
->chris?
Comment 3•23 years ago
|
||
am also seeing this using 2001.04.02.08 comm bits on linux.
Comment 4•23 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
Comment 5•23 years ago
|
||
I wasn't.
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
Comment 7•23 years ago
|
||
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 2001060121
With mozilla 0.9.4 on RH 7.1, the following problem exists: mozilla http://www.mozilla.org works whereas 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•22 years ago
|
||
*** Bug 134388 has been marked as a duplicate of this bug. ***
Comment 10•22 years ago
|
||
*** Bug 109765 has been marked as a duplicate of this bug. ***
Comment 11•22 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. http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/src/nsCommandLineService.cpp#164 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++; 162 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•22 years ago
|
||
*** Bug 168640 has been marked as a duplicate of this bug. ***
Comment 13•22 years ago
|
||
I'm upping this to major. Given that mozilla http://www.yahoo.com -parameterthatdoesnttakeanything doesn't work (invalid syntax) and 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.
Comment 14•22 years ago
|
||
*** Bug 155210 has been marked as a duplicate of this bug. ***
Comment 15•22 years ago
|
||
this is a workaround mozilla -parameterthatdoesnttakeanything dummyargument url e.g. mozilla -quiet xx http://www.yahoo.com
Comment 16•22 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•22 years ago
|
||
*** Bug 176164 has been marked as a duplicate of this bug. ***
Comment 18•21 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•21 years ago
|
||
Alex: that is a different bug
Comment 20•21 years ago
|
||
It seemed to be alike. I filed the bug separately: http://bugzilla.mozilla.org/show_bug.cgi?id=205495
Comment 21•21 years ago
|
||
*** Bug 211526 has been marked as a duplicate of this bug. ***
Comment 22•21 years ago
|
||
*** Bug 225812 has been marked as a duplicate of this bug. ***
Comment 23•20 years ago
|
||
*** Bug 40481 has been marked as a duplicate of this bug. ***
Comment 24•20 years ago
|
||
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.
Comment 25•20 years ago
|
||
Comment 26•20 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 27•20 years ago
|
||
Comment on attachment 163578 [details] [diff] [review] "not this bug" Not this bug
Attachment #163578 -
Attachment is obsolete: true
Comment 28•20 years ago
|
||
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•20 years ago
|
||
*** Bug 275434 has been marked as a duplicate of this bug. ***
Attachment #163578 -
Attachment description: Fix → "not this bug"
Comment 30•19 years ago
|
||
*** Bug 319772 has been marked as a duplicate of this bug. ***
Updated•17 years ago
|
Assignee: blizzard → nobody
QA Contact: bugzilla → cmd-line
Comment 31•15 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.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•