A missing image should return some data to say the
image is missing, not just reject the promise.
Bug: T169337
Change-Id: Ib41a64a783c1baca88f428417c98e7fb913d14a1
We were incorrectly handling transclusions with trailing
newlines after the template name.
This also improves handling of non-template transclusions,
e.g. parser functions like `{{int:mainpage}}`, which are
no longer mangled as if they were page names.
ve.dm.MWTransclusionNode#isSingleTemplate will now match
a template even if it's name is itself template-generated.
Logic for turning Parsoid's hrefs into page names stolen
from ve.dm.MWImageNode.prototype.getFilename.
Bug: T167613
Change-Id: Ibecf71338eb37bb3da81a7372e4ed41140a9af57
Sub-classes want to dynamically change type, e.g. inlineFoo/blockFoo,
but doing this after storeGeneratedContents invalidates the cache,
so ensure this is done as soon as the element is generated.
Bug: T151130
Change-Id: I80e2f2587cff8e9d9fe6ded5d8581263268deaa8
Back in de98382a55, references to MWTransclusionTableCell were introduced,
but weren't followed through on. So, actually add it. Have cellable
Transclusions use it as their type.
Bug: T144122
Depends-On: I054f12f4218102a12d7a9ea843f9c61e8825c52c
Change-Id: I367f878bfd1c58e20b62368cb78120604b48d791
After 79ccfb9372cb57afa569036ef39ead13abfba673, MediaWiki's `<pre>`
tags get rendered as `<pre typeof="mw:Extension/pre">` in Parsoid HTML.
MediaWiki's indent-pre syntax (block indented by a single space) is
still rendered as `<pre>` in Parsoid HTML, however.
Indent-pre is still handled by MWPreformattedNode (no changes).
Introducing MWPreNode, which will handle `<pre>` extension tags,
and MWPreDialog to change its contents (and allow converting
to MWPreformattedNode).
Pieces copied from MWGalleryNode, MWLinkNodeInspector, CommentInspector.
Possible future improvements:
* Add a specific icon for MWPreContextItem
* Avoid API roundtrips for rendering (but rendering wikitext <pre>
is not as simple as it looks)
* Consider a way to insert these other than '<pre' sequence
Bug: T159900
Change-Id: I5bc4ea6e5d893736f65ef0dd43b08c18cb1a1e85
We don't support editing <div>s right now (as they're BranchNodes) nor
<span>s (as they're annotations), but most of those are inside templates
and so not editable in VE anyway.
Bug: T157989
Change-Id: I647b2a544fd16952696d0de8d07cb72189b27ecb
These are actually configurable via MediaWiki messages, so use those
instead of hardcoding the default URLs.
Change-Id: Ie66a1b53f9c011947fe9e8db198a5904373f3192
New changes:
14b5fbc [BREAKING CHANGE] Move originalDomElements to the IV store and use MD5
c5d21f0 Provide methods to (de)serialize transactions
Local changes to move originalDomElements to IV store
Depends-On: I8a71c1a40ec35108d0a9a388da6f75632f8dc53c
Depends-On: I32c9b5f984fcf96e3354841ecfcd444149e8f159
Change-Id: I0fbb6324eede94558426178cbdad6b5daf0f8318
This replaces ve.safeDecodeURIComponent(...).replace( /_/g, ' ' ) . This action
is really specific to the quirks of mediawiki title processing.
Change-Id: Ia9e525c9340e6de9e485355899996c97867ccb48
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
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
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
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
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
