I'm more in favor of leaving no garbage behind. The TODO with a date
is a good way of making sure this gets removed eventually.
This could have been part of Ie6eea76. The new code is added to the
same spot where the code removed in Ie6eea76 originally was.
Bug: T296471
Depends-On: Ie6eea76dacdc614ecb910c48e7e1f519b8c69322
Change-Id: Idec63201ff4aa52a0c53c6d007577a93c94e0ec0
Following the MediaWiki changes from T301203, we should use
the messages 'skin-view-edit' and 'skin-view-create' instead
of 'edit' and 'create'.
(Also remove redundant definitions in extension.json, we load
all messages listed in 'VisualEditorTabMessages'.)
Bug: T310529
Change-Id: If055fa2a4dc009be869425e6c2262c9b62056179
The "mediaClass" property now only serves to capture the original class
found on the media so that it can be roundtripped without causing dirty
diffs. In the 2.4.0 version of Parsoid's output, that will still be
the usual Image/Audio/Video. As of 2.5.0, it will always be File and
the mediaClass property can be dropped.
Parsoid is currently forward compatible with serializing mw:File, so
edited or new media can use that type already.
The contextmenu item for media has been updated to make use of the
"mediaTag" instead of mediaClass to continue distinguishing media types.
That was the only place a grep of mediaClass turned up any use.
Bug: T273505
Change-Id: If5dc6b794dacd6973d3b2093e6b385591b91d539
Before the (intentional) design decision was to not do anything special
when the same parameter is used multiple times (via aliases). Garbage
in, garbage out. Only the first usage of the parameter would work as
intended. The rest was ignored and subsequently removed from the
wikitext.
New design decision: Track and display duplicates as they appear in the
wikitext.
Notes:
* It's not possible to create such a situation in VE. Do this via
wikitext.
* Labels will be made distinguishable via T309198.
* Possible warning messages will be added later.
* The behavior when unchecking a duplicate will be specified later.
Bug: T309198
Bug: T310248
Change-Id: I6011344638cdad8529d8f57513ef51b5237eb878
Parsoid stopped emitting figure-inline in content version 2.2.0 and VE
requests 2.4.0, which isn't satisfied by the earlier versions.
Change-Id: I5f47fbe85fdca7fe429952709b62f5d1cc548daf
This only happens in AMC. Currently it is also not possible
to update categories in VE, but this may become possible if
we enable 2017WTE on mobile.
Change-Id: Ifeb6cc18910ce2fca634bc3e2245aac7e5c37e52
The previous comment was true, but we forgot another edge-case. The
same parameter can appear multiple times. The old code tried to
delete it 2 times, which deleted something else.
Note that the behavior for duplicates is larely unspecified. We
will work on this soon. This is only a first quick step to fix this
specific bug.
Bug: T309203
Change-Id: If0afb2c19626c3d9db0d109d6559ae74698ed378
This avoids a meaningless attirbute change with the image
is unmodified (as thumbUrl can be a different size).
Change-Id: Ib79a4703382552e38022a3f345ca5cd762c52303
Needed after Ia18f31a299338f94e69f1882e6e477f3a22ae905 in VE core.
Bug: T307849
Depends-On: Ia18f31a299338f94e69f1882e6e477f3a22ae905
Change-Id: I87f3ac0974702ecaf7f5459604371de06f4a5756
Now done in VE core since Ie86217ba5651df8c427464e460ed836903834a3c.
Bug: T308200
Depends-On: Ie86217ba5651df8c427464e460ed836903834a3c
Change-Id: I3f65b0bc100895f7bd2262c3cbb5231fb055758b
* Implement ve.dm.MWGalleryImageNode.static.isDiffComparable to
match ve.dm.MWImageNode, in that images with different resources
are not compared.
* Diff galleries as documents so remove/inserts are rendered.
Bug: T308747
Change-Id: Ide6f4110e65cad7f6bb6d13766815413602fd991
Visual Editor currently requests MediaWiki DOM version 2.0.0
when talking to Parsoid. Since Parsoid treats that as a request
for 2.4.0, its current version, and Parsoid doesn't have a
2.4.0->2.0.0 downgrade path, passing the latest Parsoid version
(2.4.0) should make no difference in practice -- but would better
match current reality.
Change-Id: Ia2bc0c1981db6f573a69fb1910cef4304c80ae00
Now that Parsoid's ServiceWorkers have been merged to core, this adds
support for "zero configuration Visual Editor" to the master branch.
Like earlier zero-conf work, this does not use RESTBase for stashing
or for reliable selective serialization. Future integration work
with ParserCache will reintroduce this functionality. Nevertheless,
this implementation should have feature parity with the "loopback interface"
zero conf VE we've been shipping since 1.35.
Bug: T305108
Change-Id: I7b5b4a6d16b07914f947cbaf498ad1d3cf2447a5
