22836 - Spaces in <A HREF="file.exe "> not trimmed for 'copy link location'

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[Neil Marshall]

I'm not sure if this is a "bug" but the code works in nav4 and ie4 so I think it
should work in mozilla.

Our CGI Script generates a link on an HTML page.  Moz gave me a 404 error when I
clicked on the link.  When I viewed the source the executable is listed like
this:
<A HREF="http://www.whatever.com/file.exe                   ">Click Here</A>

Now I know the CGI shouldn't be doing that, but I think the browser should
accept it anyways.

Comment 1

[John Morrison]

Attachment: testcase; A HREF with leading, trailing and leading+trailing spaces

Comment 2

[John Morrison]

I'm not entirely sure if this is Parser, or whether something 'higher
up' should normalize HREF with leading and/or trailing whitespace, but
I'll start this with Parser. Testcase attached.

Comment 3

[John Morrison]

Doh! Sure, write a testcase, but don't actually test it until after I
attach it.

Ummm, this testcase works (clicking on the HREF with leading and/or trailing
spaces takes the browser to the "trimmed" URL with 1999123008 Win95).

The only 4.xP difference is that 'Copy Link Location' preserves the whitespace
(but that's not mecessarily a bad thing). Anyone want to mark this WORKSFORME?
marshall? Does the testcase work for you?

Comment 4

[Neil Marshall]

This is really odd.  It didn't work, at work, but it does at home.  Even the
origional page which I found the bug on, now works.

I used to get a 404 error (only in mozilla, nav and ie worked) and now it finds
the file.  I guess you can mark it as WORKSFORME.

Comment 5

[John Morrison]

Well, let's call this bug dead for the 404 error. I'd mark this WORKSFORME,
but I'll leave the one 4.xP issue for rickg/harishd to consider -- spaces are
not trimmed when passed to 'copy link location' -- (but that's not necessarily
a bad thing to preserve as long as URL resolution works OK ... Setting severity
'trivial'.)

Comment 6

[rickg]

The parser doesn't do this kind of data manipulation. That's up to the code that
handles links, so I'm forwarding on to Don.

Comment 7

[don]

Bill, is this our bug?

Comment 8

[ekrock's old account (dead)]

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Comment 9

[don]

Move to M16 for now ...

Comment 10

[don]

Move to M21 target milestone.

Comment 11

[Blake Ross]

*spam* changing qa contact from [e-mail] to me ([e-mail]) 
on 121 open or resolved (but not verified) bugs.  sorry for the spam everybody, 
but most of these bugs would just remain dormant and not checked by QA 
otherwise.  I'm not sure how so many bugs have nobody as their QA contact, but 
I suspect this is the fault of some sort of bugzilla corruption that happened 
at some point (most of these bugs are in the 20000-26000 range, and I don't see 
where in the activity log that QA contact explicitly changed to 
[e-mail])

Anyways, sorry again for spam.  If you really get annoyed, I'm usually 
available in #mozilla on IRC for torture.

Comment 12

[Hixie (not reading bugmail)]

*** This bug has been marked as a duplicate of 42287 ***

Comment 13

[Blake Ross]

hmm..are you sure this is a dup?.  This is that copy link location doesn't trim 
leading/trailing spaces in an URL, whereas 42287 is that leading/trailing 
spaces aren't trimmed from an URL before attempting to resolve it.  I think 
that can be fixed without this (but I may be wrong...is 42287 that the spaces 
should be trimmed whenever the value of the href attribute is obtained?)

Comment 14

[John Morrison]

Yeah, it's a subtle difference, and I pondered it, but was going to let it go
since it's not even clear to me what the preferred behaviour is for a user
copying a link location: trim leading/trailing spaces or give it to the 
clipboard verbatim. Trimming is probably better (and possibly correct w.r.t.
HTML4), but this is a very minor issue (how often do these type of URL's show 
up).

Comment 15

[John Morrison]

I don't know when, but this works now. 'Copy link location' left/right trims
the whitespace (spaces and TAB), as well as CR and LF, before putting the URL
on the clipboard. mac/linux/win32 20000806nn. This bug is outta here ...

Comment 16

[sairuh (rarely reading bugmail)]

vrfy fixed on linux/mac/winnt using 2000.09.15.06/8/5 opt comm bits.

Comment 17

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/3da5c1ee6128
[fenix] For https://github.com/mozilla-mobile/fenix/issues/22836 - Replace primary_text_private_theme with fx_mobile_private_text_color_primary color token