New changes:
fe82a8073 Update OOUI to v0.35.1
c9ed3a117 Localisation updates from https://translatewiki.net.
552d703b7 Localisation updates from https://translatewiki.net.
cab4264f1 build: Unbreak language lists, swapping 'szy' language for old 'ais' code
25b446256 Localisation updates from https://translatewiki.net.
0cd49c0c8 Avoid a "wiggle" when inserting a missing table cell
0babef010 Make test names clearer
b2939de73 TreeModifier: Ignore removed nodes properly when normalizing from a text node
Bug: T234108
Bug: T235959
Change-Id: Ifef6a96828a388f38f58ca4440f8ea6d31b1743a
(This is the error from T233127.)
It's still somewhat unhelpfully generic because it can appear in many
situations. But at least it'll be searchable, and less ambiguous about
where the 404 happened when a user reports getting this error.
Change-Id: I9e771934c436f39dd380fa5a06edcfbce9efad4c
Something is causing the 'ETag' headers produced by the "public"
RESTBase (queried directly from the client) to be mangled or lost.
My theory is that some proxy or browser extension is doing that.
When we detect a bad etag when fetching the page contents, discard
the result and try querying the "private" RESTBase via the MediaWiki
API (similar to what we do on private wikis, except there we talk
directly to Parsoid instead of RESTBase). After I463a84de63, that
returns the etag as part of the payload rather than HTTP headers,
and should pass unharmed through whatever is mangling the data.
Also compare and log the two etags.
Bug: T233320
Change-Id: I2ef0ca872597566f74b650aea71bf3f15747a6d7
For consistency, I guess. Also I need this in I2ef0ca8725.
Previously, when querying the HTML content of an existing page, we did
not return the 'etag', on the assumption that anyone who needs it will
instead query RESTBase directly.
Bug: T233320
Change-Id: I463a84de631598243893946ad1d060a9aa0b180e
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
