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
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
Depends on I1ba8978dd in core.
Bonus: remove not-allowed-cursor & highlight title (which was
broken) now that we can display this information properly.
Bug: T106810
Change-Id: I1800490ba1b8e10ff54b26372a8a78661c1c7d68
In clipboard mode we need the full body regardless of if the reference
has changed since load or not.
Bug: T104230
Change-Id: Ie59e04d381f2fd2680e8af0cf05a80df71052822
Starting with I21fbbd3247bf7801e5ef9bd5312f95777f4dd6ef, Parsoid
will emit a new HTML for its Cite extension, which enables CSS
styling. In I487095df8a7c4241a14f7b4480360f6774130bec the new
module 'ext.cite.style' is added to the Cite extension to style
this new HTML format.
This patch
* Loads the ext.cite.style module if the Cite extension is
present.
* Uses the new HTML format for the internal structure of
reference and reference list nodes, so they are correctly
styled.
Backwards compatibility: Only new HTML is used internally in VE,
so as long as ext.cite.style can be loaded the new styles will be
used. It does not depend on which format Parsoid returns, so this
patch only depends on the Cite extension patch, not on the Parsoid
one.
Note: The only way I've found of adding a ext.cite.style dependency
only if Cite is present is to register the whole
ext.visualEditor.mwreference module in the
onResourceLoaderRegisterModules hook. Maybe someone can point to
a better way?
Bug: T86782
Change-Id: Ibf333a502d64d2ed6e029221458b7c606554e414
This is a hacky fix, we should find a better way of telling the
model registry that language annotation loses to certain RDFa types.
Bug: T101977
Change-Id: I8be3aa55cbbc2832b8a02a15de27289b3041967e
Once MW images are registered, we should remove core image support so
we don't accidentally match to them (e.g. an MW inline image with an
unsupported extra RDFa type).
Change-Id: I1c8567346c371fe338f95b232c9ac53e009c5a46
The red-linked inline images in VE are now identifited as red links and image errors.
They can be changed and thereby be modified just as any other inline image on the editor.
Change-Id: Idb6f6f2da14379fd7db6ca19613dad32fe40023d
New changes:
a6144f3 [BREAKING CHANGE] Allow models to specify which extra RDFa types they support
Local changes:
* Use new allowedTypes property in model registry
* For reference nodes, allow 'dc:references'.
* For transclusion nodes, allow any other types.
* For image nodes, allow 'mw:Error'.
Bug: T98999
Change-Id: I7eb2b61eb9336792535e9fd6d5a8dd2d57065f04
The red-linked images in VE are now identifited as red links and image errors.
They can be changed and thereby be modified just as any other image on the editor.
Bug: T52788
Change-Id: I9cbb992c34d71b7073157fe276fee04e901845b1
MWExtensionNode:
* Inherit from LeafNode at the top level. Inline and block only
differ in CE where inline has isContent set.
MWAlienExtensionNode:
* Inhert from MW(Inline|Block)ExtensionNode respectively. Both
mixin MWAlienExtensionNode.
Bonus:
* Bring in paragraph unwrapping on inline nodes from MWMathNode
Bug: T93712
Change-Id: Ib04234f740cf1f27c861d8b3cfeea5e323b94678
