247664 - mozilla-xremote-client gives 509 error when URL for openURL() doesn't end with /

Status: RESOLVED EXPIRED

(Core Graveyard :: X-remote, defect)

Description

[Alexander Skwar]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9 (NESI)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9

I call the following command:

./run-mozilla.sh ./mozilla-xremote-client -a firefox openURL(http://example.net
, new-tab)

This should open the page http://example.net in a new tab of a running firefox
window. Instead, I get this error message:

./mozilla-xremote-client: Error: Failed to send command: 509 internal error

That is because the URL I passed into openURL() did NOT end with a / and
specfies a domain. IOW: when I pass http://example.net/, the above command works
just fine. It just does not work, when the trailing / is missing (ie. when the
URL is "http://example.net").

Since it's of course possbile to type this URL in the adress bar of the running
window, it should also be possible to use this URL in openURL().

This run-mozilla.sh command is also used in the firefox/mozilla starter script
as proposed in bug #177996 (attachment (id=150144)).

Because of that, and becuase the script might be invoked "indirectly" as a
handler in numerous parts of the GUI environment, it is not possible (or
realistic) to expect the user to always pass along a completely correctly formed
URL (ie. one that ends with a /); eg. the user might click on a URL in some
application. Well, because of that, mozilla-xremote-client (or openURL()) should
also accept not so well formed URLs like ones ending without a /.


Reproducible: Always
Steps to Reproduce:

Comment 1

[Alexander Skwar]

(In reply to comment #0)

> I call the following command:
> 
> ./run-mozilla.sh ./mozilla-xremote-client -a firefox openURL(http://example.net
> , new-tab)

Uhm, I actually call the following command:

./run-mozilla.sh ./mozilla-xremote-client -a firefox "openURL(http://example.net
, new-tab)"

Note the enclosing quotes around openURL().

Comment 2

[Dan Sandberg]

This is present in 1.7.1 (linux).  This definitely used to work in versions
prior to 1.7.    Opening a URL through the command line without a "/" suffix AND
with the new-tab option results in the following:

[dan@localhost:/home/custom/apps/mozilla] ./mozilla -remote "openURL(
http://www.google.com, new-tab )"
Error: Failed to send command: 509 internal error

Strangely, it works fine without the new-tab option.

Comment 3

[Marc-Jano Knopp]

Hotfix for scripts:

Instead of

  mozilla -remote 'openURL(%s, new-window)'

use

  mozilla -remote 'openURL(%s/, new-window)'

Though it's not really nice, it seems to work
for all URLs I have tried.

Comment 4

[Alexander Skwar]

(In reply to comment #3)
> Hotfix for scripts:
> 
> Instead of
> 
>   mozilla -remote 'openURL(%s, new-window)'
> 
> use
> 
>   mozilla -remote 'openURL(%s/, new-window)'

!DO NOT USE THIS! http://example.com/?val=me is *NOT* the same as
http://example.com/?val=me/!

However, we might want to remove the ", new-window" part. I don't quite
rememvber why I added this part, but thinking about it, it makes sense to *NOT*
force new-window or new-tab but instead have Mozilla decide about the "open type".

Comment 5

[Alexander Skwar]

Uhm, I mixed up bugs here ;) The part about me adding ", new-window" to
something was refering to the new starter script in bug #177996 ;)

Got confused here *G* Sorry about that.

Comment 6

[Robert Parenton]

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

Comment 7

[Marc-Jano Knopp]

You are right, Alexander, the hotfix works only for
a limited range of URLs. But that's the reason I
called it "hotfix". :-)

Comment 8

[Marc-Jano Knopp]

I just wanted to add that I initially thought it
would work, because the servers I tested treated
e.g. "index.html" and "index.html/" identically.

Comment 9

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 10

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.