Page MenuHomePhabricator

Autolinking for URLs and magic links (ISBN etc.) not applied when copy-pasting a block of text
Open, LowPublic

Description

Autolinking is not applied when copy-pasting a block of text, only when copy-pasting just the autolinkable string.

For example, copy-pasting these works – the VE core logic to autolink URLs, and the VE-MW logic to autolink magic links like ISBNs, kicks in:

  • http://example.com/
  • ISBN 1234567890

But when copy-pasting these, it doesn't:

  • Visit http://example.com/ to see an example.
  • Doe, John (2000). On examples. Example Publisher. ISBN 1234567890.

In particular, when copying a large block of content into a wiki page (e.g. an article you drafted in a text editor, or a notes from a session in an Etherpad), any links and ISBNs in it will not be autolinked, and will end up in wikitext wrapped in <nowiki>.

Event Timeline

matmarex created this task.Apr 5 2017, 5:50 PM
Restricted Application added a project: VisualEditor. · View Herald TranscriptApr 5 2017, 5:50 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Jdforrester-WMF triaged this task as Low priority.Apr 5 2017, 5:53 PM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

This is intentional product design (as external links in copy are explicitly not wanted for MediaWiki users), but maybe it should be disableable by the platform (so it works in VE but not VE-MW) and by special kinds of links (like ISBNs)?

To be clear: I mean copy-pasting the examples as plaintext (e.g. from Notepad, or from a regular textarea on a web page). I don't mean rich text / HTML <a> links.

(This was filed as a "follow-up" to T162095.)

Yeeeah… maybe it'd be OK to have different behaviour if you were to paste foo http://www.example.org/ bar and get links, and <p>foo <a href="http://www.example.org/">http://www.example.org/</a> bar</p> and not, but I'm not wholly convinced users wouldn't be confused (the latter would nowiki as now).

If we're instead doing entirely a let's-reduce-nowikis pass after all pastes (regardless of source) in VE-MW to convert inline http://www.example.com/ to <a href="http://www.example.org/">http://www.example.org/</a> that's… more interesting, but possibly a bit magic? I dunno.

Schnark added a subscriber: Schnark.Apr 6 2017, 8:06 AM
Elitre added a subscriber: Elitre.May 4 2017, 9:58 AM

This problem seems to apply when you paste rich text (such as from a google doc) where the URL is already linkified. For example, this is in a gdoc, with the URL linkified:

Advanced edit quality support for Romanian Wikipedia incoming (https://phabricator.wikimedia.org/T156503)

If you copy and paste that into VE, the link becomes <nowiki>'d plain text. I would have expected rich links to come through unharmed, rather than having to go back through the auto-link process.

I wanted to add that this is very frustrating for those of us who paste meeting notes into mediawiki.org. There are often links to phabricator tasks, wiki pages, articles of interest, etc.

Would it be easy to enable/disable rich text link preservation on a per-wiki basis? I would think that some non-wikimedia sites running mediawiki would find link preservation really helpful.

Elitre added a subscriber: Deskana.Jul 28 2017, 4:08 PM
Restricted Application added a subscriber: Danmichaelo. · View Herald TranscriptJul 28 2017, 4:08 PM
Elitre added a comment.Dec 6 2017, 7:15 PM

I wanted to add that this is very frustrating for those of us who paste meeting notes into mediawiki.org. There are often links to phabricator tasks, wiki pages, articles of interest, etc.
Would it be easy to enable/disable rich text link preservation on a per-wiki basis? I would think that some non-wikimedia sites running mediawiki would find link preservation really helpful.

@Deskana , I think this is now going to be addressed by T145252, what about the rest of the task?

Restricted Application added a subscriber: jeblad. · View Herald TranscriptDec 6 2017, 7:15 PM

@Deskana , I think this is now going to be addressed by T145252 […]

Most, but not all, of it. The solution to that task attempts to preserve bold, italics, underline, strikethrough, superscript, and subscript, but nothing else. The "correct" way to handle other things, such as links, is unclear per T162291#3158146.

[…] what about the rest of the task?

What, exactly, is "the rest"? This task has been pulled in a few different directions, so I'm not clear what exactly is being requested any more.

Is this faulty edit (internal anchor links with manual superscript, and nowiki tags around ISBNs) related to this open bug?

https://en.wikipedia.org/w/index.php?title=Charles_James_%28designer%29&type=revision&diff=815077031&oldid=805363780

Is this faulty edit (internal anchor links with manual superscript, and nowiki tags around ISBNs) related to this open bug?
https://en.wikipedia.org/w/index.php?title=Charles_James_%28designer%29&type=revision&diff=815077031&oldid=805363780

I doubt it. The problem you've described seems like a different one.

This problem (adding nowiki tags around ISBNs in Visual Editor) is still happening. Here's an edit from 6 November 2018:

https://en.wikipedia.org/w/index.php?title=Chuang_Che&type=revision&diff=867577478&oldid=867567666

Please stop Visual Editor from adding these nowiki tags. They prevent magic linking from working, and bots converting magic links to templates will avoid ISBNs inside nowiki tags.

Deskana removed a subscriber: Deskana.Nov 27 2018, 12:33 PM