New changes:
8ff4683d3 libs: Update papaparse to 5.1.0
210518d4a eslint: Remove unused prefer-template rule; use proper globals values
fd8bf7425 Localisation updates from https://translatewiki.net.
f09a8f327 Remove <style> tags from $pasteTarget immediately
0f76791ac lib: Unset the executable bit on the papaparse.js library
8d05203fa TreeCursor: cross ignored nodes properly from the end of a text node
Bug: T234881
Bug: T235068
Change-Id: Icf9e0ca80575e45577ebf51764247da4dd82bdba
Previously, the ve-mw/init/ directory contained two kinds of files:
those that were used when initializing VE, and those that may be
loaded even if VE is not going to be initialized at all. The latter
kind must not use the `ve` global variable.
After moving those files to ve-mw/preinit/ we can enforce this with
.eslintrc.json in that directory. This would have prevented T228684.
(Technically they merely must not use `ve.init`, and may use `ve`,
but that's harder to enforce. We should instead move the few non-init
methods out of `ve`: now, track, trackSubscribe, trackSubscribeAll).
Also, group some files under ve-mw/init/: targets/ now (only)
contains ve.init.mw.Target and its subclasses, apiresponsecache/
now contains ve.init.mw.ApiResponseCache and its subclasses.
Bug: T228684
Change-Id: I945249a27f6a0fa10a432d5c5dc57bc7e0461fd8
New changes:
fec3647e7 TreeModifier: return correct position in ensureNotText
2c8e48194 TreeModifier: Ignore more attributes when validating linear data
Bug: T234489
Bug: T234742
Change-Id: Ib83dfa2f2e02a63a8e9774f3383e5796a624cb64
The ...target.wt property contains the wikitext used to generate
the template name. It can contain trailing newlines (T234817) and
all kinds of funny wikitext syntax. Instead, use ...target.href,
which is the title of the page that is actually transcluded. Compare
the new code to ve.dm.MWTransclusionNode.prototype.getPartsList.
Additionally, fix some confusion about namespaces (treating template
names as titles in the main namespace). The template names in the
configuration page (visualeditor-template-tools-definition.json)
now support overriding namespaces in the same way as in wikitext.
Bug: T234817
Change-Id: I7c557d28e961d0b9117fc0380c65cdd42035ae96
If you had an image thumbnail for a file 'Foo?.png' on the page,
ve.ui.MWMediaContextItem and ve.ui.MWMediaDialog did not escape
the '?' when linking to it, which resulted in incorrect links.
Similarly, if you had an internal link to the page 'Foo?',
ve.ui.MWInternalLinkContextItem did not escape it.
Additionally, the links were always generated as if the wiki was
using short URLs, even when it is not (T233628).
The approach using mw.Title is copied from ve.ui.MWGalleryDialog.
Bug: T233628
Change-Id: I10256ed6883dae0ea216de4c0719f03d7fd19ae4
The 'eye' icon is in the 'accessibility' pack, not 'alerts'.
Compare to the dependencies of 'ext.visualEditor.diffPage.init'.
Change-Id: Ie14ab6be756fd9e0bef59475466674a41273046f
* In normal images, parse relative 'href' attributes instead of
expanding them to absolute, and parse 'resource' to keep it
identical to 'href' if they refer to the same page (including
same percent-encoding and space/underscore). This resolves Parsoid
generating |link= options for copy-pasted images (T193253).
* In gallery images stuff, prefix the 'resource' attribute with './',
same as normal images do. This causes no functional changes, but it
makes updating tests easier, and the consistency is probably good.
* Update test examples to also prefix 'resource' and relative 'href'
attributes with './', like the real Parsoid does.
Bug: T193253
Change-Id: If2d7f080d9d693568054f8311c1e1b15ca27ea5c
* 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
In order to get the desired padding, the `em` values were pre-multiplied
by the parent font-size, which was assumed to be `0.875em` for normal
surfaces and `(13.3333/16)em` for wikitext surfaces. (That should have
been `(13/16em)`, by the way, but that's a negligible difference.)
Unfortunately, the font-size for wikitext surfaces is actually `13px`.
Unlike `em`, `px` values are not affected by custom browser font-size,
so when one was set, the final padding was all out of whack.
Use `rem` units instead to respect the custom browser font-size,
without getting problems due to the parent element font-size.
We don't need separate rules for .ve-ui-mwWikitextSurface now.
Bug: T222217
Change-Id: Ib7ffbf09d5aa23fddb894aa3b081ec993ddcee2d
