I can confirm what Valerio describes. What is going on at a first level is that the clicking on the link places two entries in the clipboard: a text/html entry and a text/plain entry. So the behavior varies depending on where this is copied:
When copied in a context that understands text/html, like word processors, spreadsheets, many email clients, it becomes a link whose text is reflective of the type of content (a numbered reference if one is possible, or a word like Paragraph etc).
When instead it is copied into a context that doesn’t understand text/html, like the web browser’s location bar or a plain text editor, it is the text/plain version that is being used.
And here lies the “problem”, or in any case the choice that we have made at the moment: This plain text version consists of two lines of text, the first line being the same label that is used in the text/html link as the text for the link, and the second line being the actual link.
in a location bar the newline separator basically goes away, hence Valerio’s behavior.
Personally I would much rather prefer it if the text/plain version was just the link and nothing else, that is what you expect to get when you “copy a link”. In almost every case where I need to do this, I have to then clean up the pasted result to remove the label.
I think it’s up to us to decide which way that should work. But this is why it behaves as Valerio describes at this point, because of what we ship as the text/plain version of the copy.
Charilaos Skiadas
Department of Mathematics
Hanover College