Redlinks now come down with a `mw:LocalizedAttrs` typeof, and have the
display URL parameters rather than being bare titles.
Bug: T324352
Change-Id: Ia1776e6e1f171d227c7c402b39ca96d17fb56cdb
This patch follows the audit made on the extensions to check the usage
of the "rel" attribute and check that it's compatible with multi-values.
Bug: T315209
Change-Id: Ib323736d93ea96c86f9d56599e515c9e6d72a76e
It is no longer necessary to prepend a colon in Parsoid HTML
to ensure they are interpreted as links rather than an image
inclusion or categorization.
Instead, the colon causes Parsoid to generate piped links
when they could be unpiped, so remove it.
This code was added in 1e62e9f64c (2012),
the Parsoid bug was fixed in b62b93c678 (2013).
Bug: T312700
Change-Id: I3d71fd658b5dd627445e60b850f647081ef842e7
Bring in ve.dm.MWInternalLinkAnnotation.static.getTargetDataFromHref
and ve.resolveUrl, so that the file has no dependencies on VE.
Change-Id: I03bc455d5484a6c51f3fa2397c64936b829fe7e3
* Handle mw:MediaLinks pointing to to non-existent files, which come
with typeof="mw:Error" (similar to image nodes).
* Fix regression from c66f8e0547, which
caused all mw:MediaLinks to be treated as plain external links again.
* Add test cases.
Bug: T232754
Change-Id: I9ae5bcfc4e24e8c0d22ef77d6a4d03f817fc9768
As detailed in T95850#5078990, Parsoid incorrectly converts HTML to
wikitext when a link `href` refers to an interwiki page and contains
percent-encoded colon characters ':'. VisualEditor doesn't know
anything about interwiki pages (it treats those links as normal local
links, and expects MediaWiki and Parsoid to handle them specially),
so we can't easily special-case them. But since leaving the colon
unencoded is valid for all links anyway, we can just do that.
Bug: T103635
Change-Id: I87d7e6952983a72d90ea739b0bc8488d9f6a9be3
The likely case for this is: copying from within VE in one wiki, and pasting
into VE in another wiki. This change will notice this happening, and fall back
to treat it as an external link. (For the wiki-internal links, this will turn
them into interwiki links rather than raw external links.)
Bug: T223322
Change-Id: Ie0157fc3aee6e5fd9973a2889be7ebd287bc90a5
Parsoid does not use relative links anywhere anymore (T72743). There
is no reason for us to support this. And previous code allowed
"hrefPrefix" to be empty '' sometimes, which is scary, as it could
lead to XSS vulnerabilities if titles starting with 'JavaScript:' are
not handled correctly elsewhere.
Bug: T206357
Depends-On: I8728f63084902c76d1c61193be4367939b069f1a
Change-Id: I99be18877aae2b505cf261bd7cdef6cf0d7a8670
We could generate incorrect links to pages whose title contains a
colon ':' and therefore looks like a fully-qualified URL.
Bug: T206231
Bug: T206357
Change-Id: Ie34694d903a6d97589cc46417f70659559494619
* When ve.ui.MWLinkAnnotationInspector is being initialized,
internal and external annotation inspectors are hardcoded to
new ve.ui.MWInternalLinkAnnotationWidget and
new ve.ui.MWExternalLinkAnnotationWidget. Make this creation
more flexible by creating these inspectors through a method,
which inheriting classes can override.
* In ve.ui.MWLinkAnnotationInspector.getAnnotationFromFragment,
factor out the creation of link annotations, so overriding
classes have the ability to provide different internal and
external annotations.
* In newFromTitle, static method of MWInternalLinkAnnotation,
creation of `element` isn't flexible for reusability with
slight changes to attributes passed to the constructor. By
factoring out the creation of attributes, inheriting classes
can reuse the existing structure and alter the attributes if
needed.
Bug: T195064
Change-Id: I2037464a7be77783837e9810691c8e372c8197c6
New changes:
71baf1c02 Create an 'htmlMsg' function for HTML messages with HTML or DOM arguments
9a7af223e Use ve.htmlMsg to highlight values in attribute changes
a1fd90540 DiffElement: Refactor describeChanges tests
Local changes:
Implement getHtmlMessage in mw.Platform and use for DiffElement
Bug: T195243
Depends-On: Ib4ad16858e4241d33d018830dbcfded63ff703af
Change-Id: Ib5fa39e4f2f529948354b03a141542e23d169fe0
It was failing to properly ignore the fragment if it contained a ?. This
resulted in such fragment-selflinks being considered a link to a wikipage with
a title of their full URL. As such, only consider the pre-# section for ?s.
Bug: T194463
Change-Id: I205f86d2b4abcf91dd6a84e3013e899e953a6842
Let's keep the ugly regexp and the comments about why we do this in a
single place.
This is mostly without behavior changes, with three exceptions:
* ve.dm.MWImageModel#attachScalable now passes a title with spaces
instead of underscores to the Scalable (this doesn't matter because
it's normalized to use spaces later anyway).
* ve.dm.MWImageNode#getFilename now returns a title with spaces
instead of underscores. This is used in some API queries and when
rendering thumbnails for missing files, and this format is actually
more correct for both of these.
* ve.dm.MWTemplateModel now URI-decodes the template title. This
actually fixes a bug where trying to edit a template transclusion
whose title contains a '?' would throw an exception about invalid
title.
Also, clarify that the return value of ve.dm.MWImageModel#getFilename
and ve.dm.MWImageNode#getFilename is different :(
Change-Id: I8e09015cea82308017ed925ec755b7231518126e
Original title will preserve the case of what the user entered
into the inspector. Noramlized title will remove any unwanted
leading colons from file/category links.
Bug: T118408
Bug: T124410
Bug: T160977
Change-Id: I92ffc19eab4eead0d124e84afc1e5a0a3e535867
<a href="Foo%3F"> would dirty-diff to <a href="Foo?"> and also render
as such, pointing to the wrong page.
We also called decodeURIComponent() on the href twice, which can't
have been good.
Move URI decoding and underscore normalization into
getTargetDataFromHref(), and add rawTitle for callers that need it.
Put rawTitle in the origTitle attribute, so that equivalence
comparisons (decode(origTitle) === title) work as intended.
Bug: T145978
Change-Id: I29331a4ab0f8f7ef059c109f6813fa670a2c7390
TODO: Do we need to do anything special here to handle multiple hash symbols in a URL?
Bug: T112898
Change-Id: I4773cb04ae2533e8125bc55d9ebb606d63b3bf48
This replaces ve.safeDecodeURIComponent(...).replace( /_/g, ' ' ) . This action
is really specific to the quirks of mediawiki title processing.
Change-Id: Ia9e525c9340e6de9e485355899996c97867ccb48
Percent-encoded characters are forbidden in titles. Copying URLs around will
tend to wind up when them percent-encoded when you paste. Therefore, when
trying to build a title from a pasted link, decode it first.
Change-Id: Ia0abcb2d903b04d99c7db16eb0a5962480b138d5
This was causing a regression in the behaviour that takes you
to the external link tab automatically when 'http://' is typed,
as internally it is normalised to 'Http://'.
Bug: T112158
Change-Id: Id7cff07e89caafe5b350f4fb27b99c6c89498990
Implement a special node type, context item, and inspector for
ISBN/PMID/RFC magic links. Add buttons to the link inspectors
to convert back and forth between "simple" links, and magic links.
Depends on I5d000d8b63dafdfe0a2753069d3f0ac5b03b8829 in Parsoid
for clean round-tripping of localized ISBN magic links.
Bug: T63558
Change-Id: Id5b7a2ae3c80b0e5eed598f0bd024d3e94f7e9aa
This allows the URL paste handler to use the normalized title
as the text content. Add a test to cover this behaviour.
Depends on Ica48fea69cc in core.
Bug: T109980
Change-Id: I2784adaf2949a73256049921227dde0917ef9aef
Add ve.dm.MWInternalLinkAnnotation.static.newFromTitle to build an
appropriate internal link annotation from a mw.Title. Tweaked some
method signatures to avoid repeated reparsing of the title text.
Also refactor ve.dm.MWInternalLinkAnnotation.static.getTargetDataFromHref
to explicitly return a boolean indicating whether the result was determined
to be an internal link.
Bug: T64816
Change-Id: I74385d7b3ede1794398dabb749185f4080509b99
Currently we compare some HTML attributes, but as wikitext doesn't
allow you to set arbitrary attributes on a link they can never
represent a meaningful difference (unlike <b style="color:red;"> vs. <b>)
Bug: T95028
Change-Id: I267604e4b2140d3c4fe4f9ab07961c6f17a1f2fa
