1285741 - Hyperlink recognition eats blank/space in file name or path component

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Rainer Bielefeld]

Steps how to reproduce  NOT reproducible REPRODUCIBLE with  English SeaMonkey 2.45a1  (Windows NT 6.1; WOW64; rv:48.0)  Gecko/20100101 Firefox/48.0 Build 20160308001946  (Default Classic Theme)  on German WIN7 64bit

1. Launch SeaMonkey email client → for account "Show message body as
   plain text"
2. via Icon "Compose" as plain text for POP3 account create new email
3. copy / paste 2 hyperlinks from below to email body → as email subject
   type "link recognition test 001"
4. send to an other POP3 email-account with  "Show message body as
   plain text"
5. receive email and view in Message Pane
   » both links seem to look fine
6. move mouse pointer over first link
  bug: blank in file name is missing
7. move mouse pointer over second link
  bug: blank in file name is missing 

a) when you click the hyperlinks you will see that also in URL shown
   in Locatoin Bar the blanks in the file names are missing, so that
   you will get an error message in SeaMonkey Browser. 
   After having inserted the missing blank in URL in Location Bar the 
   picture will be shown in SeaMonkey Browser 
b) of course blanks are problem, how should a link recognition know 
   whether the blank is part of a file name or a "separator", following
   word does not belong to hyperlink? but within <> recognition should
   see the blank as a part of the file name.
b1) Ignoring the space and linking the 2 words of the file name to
    2 word is completely wrong

Currently my Thunderbird is broken, I will test with TB later.

----
Links to copy to email body:
<http://www.bielefeldundbuss.de/PRIVATRuM/SeaMonkey/bughunting session.png>
http://www.bielefeldundbuss.de/PRIVATRuM/SeaMonkey/bughunting session.png
<http://www.bielefeldundbuss.de/PRIVATRuM/SeaMonkey/b hs.png>
http://www.bielefeldundbuss.de/PRIVATRuM/SeaMonkey/b hs.png

Comment 1

[Rainer Bielefeld]

c) problem already is visible in saved Draft
d) No obvious DUPs found with <https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=DUPs1285741&sharer_id=41036>

Comment 2

[Rainer Bielefeld]

e) Already REPRODUCIBLE with SeaMonkey 2.5  (Windows NT 6.1; WOW64; rv:8.0.1)
   Gecko/20111121  Firefox/8.0.1   Build 20111121045514  (Default Classic Theme)
   on German WIN7 64bit
   (earlyer not tested)

Comment 3

[Rainer Bielefeld]

f) Same problem with Daily TB 50.0a1 (2016-07-05, so Mailnews Core problem

Comment 4

[Jorg K (CEST = GMT+2)]

I created myself a plain text mail and the body has:
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

<http://www.bielefeldundbuss.de/PRIVATRuM/SeaMonkey/bughunting session.png>
http://www.bielefeldundbuss.de/PRIVATRuM/SeaMonkey/bughunting session.png
<http://www.bielefeldundbuss.de/PRIVATRuM/SeaMonkey/b hs.png>
http://www.bielefeldundbuss.de/PRIVATRuM/SeaMonkey/b hs.png

Yes, hovering doesn't show the space and clicking opens the URL without the space.

Some general comments:
I suggest to use %20 in the URL. This is what happens when you insert the link into the composition using Insert > Link.

This is not a Mailnews problem. Curiously the linkify code, which generally stops at a space, is in M-C core here: netwerk/streamconv/converters/mozTXTToHTMLConv.cpp
No idea why it removes the space instead of stopping there (as you can see here in BMO above). Must have to do with the < > since without them it just stops.

So this is a Core::Network bug.

Last time I fixed something in there, they asked me to rewrite it, see bug 1274602 comment #22 or bug 1274242 comment #22.

Comment 6

[David Dyer-Bennet]

Well, the one just marked as a duplicate of this was a blank in a *path component* rather than the filename, but I would have just entered mine as a comment to this if I'd found this when searching originally (never occurred to me to use "blank", which is non-specific in my head, I was searching for things involving "space").

Comment 7

[Jorg K (CEST = GMT+2)]

To be perfectly honest, I haven't been able to work out where spaces are allowed and where they aren't. I saw:
http://stackoverflow.com/questions/1211229/in-a-url-should-spaces-be-encoded-using-20-or
So they're not allowed in the path and filename, right?

Looks like the the filename is part of the path:
https://dxr.mozilla.org/mozilla-central/rev/d29f84406483c721a13cf9a52936ecced0c5c98a/netwerk/base/nsIURI.idl#16