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)

Product:
Core Graveyard
Component:
Cmd-line Features
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
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
Assignee: law → mcafee
am also seeing this using 2001.04.02.08 comm bits on linux.
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.
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
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.
*** Bug 134388 has been marked as a duplicate of this bug. ***
*** Bug 109765 has been marked as a duplicate of this bug. ***
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
*** Bug 168640 has been marked as a duplicate of this bug. ***
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.
Severity: normal → major
Keywords: 4xp
OS: Linux → All
Hardware: PC → All
*** Bug 155210 has been marked as a duplicate of this bug. ***
this is a workaround
mozilla -parameterthatdoesnttakeanything dummyargument url
e.g.
mozilla -quiet xx http://www.yahoo.com
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.
*** Bug 176164 has been marked as a duplicate of this bug. ***
Blocks: 40481
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.

Alex: that is a different bug
It seemed to be alike. I filed the bug separately:
http://bugzilla.mozilla.org/show_bug.cgi?id=205495
*** Bug 211526 has been marked as a duplicate of this bug. ***
*** Bug 225812 has been marked as a duplicate of this bug. ***
No longer blocks: 40481
*** 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.
Attached patch "not this bug" (obsolete) — — Splinter Review 

    
    

    
  
> 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.

    
    

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

    
  

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

    
    

    
  
*** Bug 319772 has been marked as a duplicate of this bug. ***

    
  
Assignee: blizzard → nobody
QA Contact: bugzilla → cmd-line

    
    

    
  
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

    
  
Product: Core → Core Graveyard

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: