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
We may be trying to insert a block into a paragraph. fixUpInsertion
handles this, but not if use a replace transactions.
Bug: T136279
Change-Id: I1401da52676e79f38ef835a32d2c76004b75fb4e
Make some of the methods we currently use to render the node
static so we can re-use them before inserting. We do the evaluation
without inserting the node so as not to dirty the document and
transcation history.
In the unlikely case the request fails, just fallback to inline.
This only handles insertions for now as type changes on edit will be
very rare.
This changes the signature of insertTransclusionNode, which is used
in Cite and Citoid extensions.
Bug: T51784
Change-Id: Ibc2fc66e6866084b0a4deeb082c8a1ca412febb2
* Use TitleInputWidget for wiki-page-name and wiki-template-name parameters
* Use UserInputWidget for wiki-user-name parameters
* Use a custom hacky CheckboxInputWidget child class for boolean parameters
* Borrow some ve.ui.MWExternalLinkAnnotationWidget.prototype.createInputWidget code for url parameters
* Use a TextInputWidget with multiline disabled for line parameters
Not dealt with in this commit, so fallback to existing behaviour:
* string
* number
* unknown
* content
* unbalanced-wikitext
* date
* wiki-file-name
Bug: T55613
Bug: T124734
Bug: T124736
Change-Id: If04944d64303d959e8dd605e75a175895932b788
Depends-On: I87699a93ca1b34c6d248456fcc060f584623d158
Depends-On: I5e97604f0fc24176d5e89899bf0505dc442a1a7e
We now accept non-Parsoid generated external links from paste,
so make sure they have href attributes otherwise they aren't
really external links and will throw exceptions later on.
Bug: T131430
Change-Id: Ifb565b1ce30cfe80ae72b17f6a9551ea40b36453
ve.dm.MWExtensionNode#toDataElement calls storeGeneratedContents()
which prepopulates the cache, but because it was being called with
the wrong context, this.name was null and so the key we were storing
it under was different from the key we'd later be looking for.
Fixed by ensuring ve.dm.MWAlienExtensionNode#toDataElement preserves
context when calling its parent. Our static context hacks are tricky.
Change-Id: If859d861453067d7656a33a1767f6efc7bd9d323
Using the same logic we used for converting pasted URLs, detect
internal links by matching their base.
Currently link pasting is still disabled in the VE target, but
has been enabled elsewhere (Flow).
Change-Id: Iebd61abbe1fe82fd18d129e1dbc815ca75f44e87
Now that some targets support link pasting (Flow) we need to
make sure that pasted links match to an allowed type ('link/mwExternal')
instead of plain 'link' annotations which should never exist
in an MW document.
In a later commit we should auto-detect internal links.
Change-Id: I7faae834aa6e730c3cf93a691331a05fd0fe3d5c
* Override the static cloneElement. getClonedElement shouldn't
be overridden as doing so misses static invocations.
* Apply the same fix to extension nodes
* Fix DOM loop to reference clone.originalDomElements[ i ]
Logically depends on Id8024c171c to work.
Bug: T126169
Bug: T126114
Change-Id: Icf4d3115db5b12b97a6c805ff3d0b71d9e88b804
This prevents tables from getting sanitized even on
VE to VE copy. Also by calling ClassAttributeNode sanitize
extra CSS classes are removed.
Bug: T97462
Bug: T125220
Depends-On: Ia3ce386b2a03bc227818b10423bca72c736c0656
Change-Id: Ifd91e00b40665b446bbdcdf8859d2bb641bc0e67
Create a subclass for MediaSearch(Provider/Queue) and make the parent
class a more generic representation of API requests for media.
Change-Id: Iea8b90e829d532d210bfef3c96d6798c64e15eed
VisualEditor is usually not enabled in talk namespaces... but
sometimes it is. And when users see the button to edit with VE,
they're going to click it and expect to be able to sign their posts.
This tool is only loaded on talk pages and pages in additional
namespaces defined in $wgExtraSignatureNamespaces.
Code adapted with small tweaks from my own gadget
<https://meta.wikimedia.org/wiki/User:Matma_Rex/visualeditor-signature.js?oldid=13461327>,
which is already available under the MIT license.
Changes include:
* The tool is now always visible if the wiki allows signatures in any
VE namespaces, but disabled when not allowed in the current namespace.
* Register '~~~~' sequence to insert the signature.
* Code style tweaks for stricter lint checks in this repository.
* Documentation corrections.
Swedish translation provided by André Costa (already credited
as a translator as Lokal_Profil).
Depends on changes in VisualEditor core:
* I89fe53890ab59d12260ea6b41de802c38c24e8b9
* I14cd7efac521687ea38580341ae08ddc522edeeb
Bug: T53154
Change-Id: I6be5fb2118cf3eef5098d4c5320228aa81411ccb
New changes:
63c5f67 [BREAKING CHANGE] GeneratedContentNode: Introduce new hash for rendering
6dd1cb2 Add ve.dm.Surface#selectLastContentOffset
Local changes:
* Use new getHashForRendering in GeneratedContentNode users
As we no longer have a model hash, remove the originalIndex check
and just rely on the deep comparison of mwData (trading a deep copy
for a hash computation should result in similar performance).
Bug: T114689
Change-Id: Ida0ee0234418408b735232c633d41908a424a9ff
We don't expect users not to alter the hash (subclasses may delete items)
so make a copy of any objects we put in it.
Change-Id: I6274f47e02b9f2d53864d4a2ae80df42e6c89867
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
New changes:
184f952 [BREAKING CHANGE] ve.dm.Converter: Put static things in .static
a4c1e1e Localisation updates from https://translatewiki.net.
Local changes:
* Switch to using Converter's newly-static methods
Change-Id: If30f7b2a0de92c4c7f4d5ca57663251c132eeed2
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
Add a parentDoc parameter to the MWImageModel constructor and use
it to inherit language, direction and HTML document. Remove
getLang(), setLang(), getDir() and setDir() whose only purpose
was to propagate the language and direction from the parent document
in a hacky way.
Also add a parentDoc parameter to newFromImageAttributes(), replacing
the lang and dir parameters. Remove the unused and ill-conceived
caption parameter.
This causes caption documents to always have an HTML document
for URL resolution. Previously, this worked when editing existing
images because a document generated by cloneFromRange() (which
propagates the HTML document) was passed into setCaptionDocument(),
but it didn't work when creating new images.
Bug: T109599
Change-Id: Ida36862092cd779ffc2f04c0ecbc1164f8d71453
Add a parentDoc parameter to the MWReferenceModel constructor and use
it to inherit language, direction and HTML document. Remove
getLang(), setLang(), getDir() and setDir() whose only purpose
was to propagate the language and direction from the parent document
in a hacky way.
This causes ReferenceModel documents to always have an HTML document
for URL resolution. Previously, this worked when editing existing
references because the newFromReferenceNode() code path calls
cloneFromRange() which propagates the HTML document, but it didn't work
when creating new references.
Bug: T109599
Change-Id: I5d9d34d4343be8428318fa0b795fa54c110e34f4
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
