901067 - Remove "%0A" from end of URL

Status: UNCONFIRMED

(SeaMonkey :: Location Bar, defect)

Description

[Tom Schneider]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19 (Beta/Release)
Build ID: 20130630004618

Steps to reproduce:

On Mac OS X 10.7.5 when I have a URL displayed in a Terminal I can
double click on it to get the entire line highlight.  At that point
the OS recognizes that there is a URL so I can right click and select
the 'Open URL' option from the menu.  A SeaMonkey window launches and
at the end of the URL are the characters "%0A" visible in the Location
Bar.  For example cutting the entire line of

http://xquartz.macosforge.org/landing/

(not just the 'h' to the final '/') comes out in the Location Bar as

http://xquartz.macosforge.org/landing/%0A

Some websites will ignore the %0A but many fail.

If I copy the line into the cut paste buffer (command-C) and
I paste that URL into the Location Bar, the %0A does not appear.


Actual results:

Highlighting the line:

http://xquartz.macosforge.org/landing/

and selecting 'Open URL' the URL in the Location Bar becomes:

http://xquartz.macosforge.org/landing/%0A

and the website responds:

> Not Found
>
> The requested URL /landing/ was not found on this server.
> Apache/2.2 Server at xquartz.macosforge.org Port 80

If I remove the %0A, the web page appears.

google:
%0A
gives
http://answers.yahoo.com/question/index?qid=20071016190923AAGP38Y
which says that %0A is a linefeed character.

I have reported this problem to Apple repeatedly.  In 10.6.8 they
added a second 'Open URL' option that did the right thing.  But then
somebody (stupidly) removed the wrong option.  They have not fixed it.
(I don't have 10.8 so don't know if the bug is there.) 


Expected results:

If SeaMonkey sees a %0A in the URL, it could remove it.

Comment 1

[Philip Chee]

As far as I know we remove/ignore literal linefeed characters. Something else must be escaping the LF before sending the URL to SeaMonkey.

Comment 2

[Phoenix]

And if you just copy that line and paste it into Address Bar, does it contain additional characters?

Comment 3

[Tom Schneider]

(In reply to Phoenix from comment #2)

It contains the URL characters and a 'carriage return' (ASCII character 13 cr).
It does NOT contain a 'line feed' or 'new newline' (ASCII character 10 nl)!
(On the Terminal type `man ascii`, look in 'The decimal set'.)

Comment 4

[Tom Schneider]

Further detail:  I did the above by copying the line (with the mouse) from a Terminal
and then using the Mac OS X program pbpaste to put the result in a file.  I then
examined the file with my wtch program
(http://alum.mit.edu/www/toms/delila/wtch.html).

When actually pasted into the Address Bar, the string does NOT contain additional characters.

Comment 5

[Philip Chee]

What if you hold down Shift+Cmd and double click the link?

Since you are on Mac OS X 10.7, try holding down the Command key and double click the link.

Comment 6

[Tom Schneider]

OH NO!  I just realized that I'm working at home on 10.6.8 where Apple offered two different URL options on their menu.  My response to the flag above was for 10.6.8.
I'll have to redo this tomorrow when I'm at work on my 10.7.5 ... sorry about that.

Comment 7

[Tom Schneider]

(In reply to Philip Chee from comment #5)
> What if you hold down Shift+Cmd and double click the link?
> 
> Since you are on Mac OS X 10.7, try holding down the Command key and double
> click the link.

Now on 10.7.5:

It's not a link per se, it's a url somewhere on a Terminal display. 
For example, I put the url into a file and then cat the file.  Then I
highlight the ENTIRE line by (double clicking the line) and a blue bar
goes across the whole page on the line of the URL.  I then select
'Open URL' and so the LF is included.

If I put my mouse over such a URL and hold down the Command key and
double click the TEXT ... just the URL text is highlighted.  Then I
can select 'Open URL' and it works!  Interesting.  That's a lot of
effort ...  (repeat 10,000 times).

Comment 8

[Rainer Bielefeld]

@Tom Schneider: Still a problem for you?

Comment 9

[Tom Schneider]

Thanks for coming back to this.  Yes the effect still occurs under Mac OS X 10.7.5.  On occasion it trips me up when the website can't handle the extra '%0A' on the end of the URL.

Comment 10

[Rainer Bielefeld]

I can't help with MAC-specific problems

Comment 11

[Tom Schneider]

(In reply to Rainer Bielefeld from comment #10)
> I can't help with MAC-specific problems

Well, that's an interesting assertion. I searched for %0A:

https://www.google.com/search?&q=%0A#q=+%250A
and found
https://answers.yahoo.com/question/index?qid=20071016190923AAGP38Y
which points out that
" In UNIX, the end of each line in a text file has just %0a. "
and links to
http://www.asciitable.com/
which confirms it (Dec = 10, "(NL line feed, new line)
So it's more generally a unix issue.  Not sure how to test this.

Comment 12

[[e-mail]]

I am running here Mac OSX 10.6.8 and I have the same behaviour with Safari (the standard OSX browser). Safari opens http://xquartz.macosforge.org/landing/%0A when a terminal line is http://xquartz.macosforge.org/landing/

(In reply to Tom Schneider from comment #11)
The line endings on Windows are CR-NL, on Unix/Linux a single CR (0x0D) and on OSX a single NL (0x0A).

So I think this is a problem of the program "Terminal", it selects with a double click a whole line including the line ending character (which is the NL) and sends this to whatever browser.

Comment 13

[Tom Schneider]

I agree, it's a Terminal problem.  But it could have been solved by removing the artificial space in SeaMonkey.  In the newer Mac OSX 10.10.5 there is nothing added to the end of the line.  Also, there are now options in the menu to get the URL and those work.  (Of course 10.6.8 still has Spaces/Expose which is a good reason to stick with it.  TotalSpaces works in 10.10.5 but can't be used securely in later OS.)