MediaWiki needs this even without VisualEditor so let's move it there.
Bug: T371702
Depends-On: I4dcfa3916a07e92565b5667adb2ead0115fdb438
Change-Id: I0562ea1e5bd28eabd3ef0bcd8372155da67bcd0c
This also resolves the bug but it hides the underlying issue on it
that's why I like to have this but after having
Ia7dd8076c8789ed04d3fb52a078c70561ee5c6f8
Bug: T371665
Change-Id: I7340829acbd2bf3fcccfb631848964e5338470b0
According to ECMAScript, .trim() and RegExp’s "\s" capture the same
characters, so I replace the initial "\s*" by .trim() to remove
whitespaces and line terminators at the beginning and at the end.
Bug: T371000
Change-Id: Id9188f97a3136b986b052b71cd4079c1109ea8ff
This can be reenabled once Cite changes are merged.
The disabled test is also updated in this patch so that it will pass
with the new Cite code.
Bug: T370512
Change-Id: I56b52c399d2c76689fdcb0bc7fd50a8c0ced28fd
Without this, wheneve VE is installed, test execution ends with the
address bar rewritten to Special:Badtitle, which affects reloads etc
and makes debugging anything else harder.
Bug: T250045
Change-Id: Ic453ae388c842369ff1cb1e84dcad4a8bbc7d54f
I spent a couple minutes looking at this before I saw that we needed
`this.updateVisibility()` to only fire if the loop iterated at least
once.
Change-Id: I7d03f73a35e3ded539898effa064dc0e14ba595f
transitionend is supported by all our target browsers.
Also use requestAnimationFrame without a fallback as
this is also supported by all browsers.
Change-Id: I563cacdc8b2365ad4b69dfccb7e46a9f176dbd9b
Replace it with a hasAddedContentNeedingReference that'll need to be
kept in-sync with the internal logic in AddReferenceEditCheck while
we're tagging this.
Follow-up to d69d366469.
Bug: T367920
Change-Id: I9f4f96bf5c6c4b7b3131b1435426b2e283c9833a
New changes:
3135ad109 Update OOUI to v0.50.0
0eb93c340 Localisation updates from https://translatewiki.net.
2e23d8cac ve.ui.Surface: Improve documentation of surface padding
d42086d50 Allow TableCellableNode to span multiple DOM elements
65e536c1c Localisation updates from https://translatewiki.net.
Local changes:
* Allow MWTransclusionTableCellNode to span multiple DOM elements
Bug: T366984
Bug: T367061
Change-Id: I67239ac72f29b9729b73c7604ee3680ceb1b8475
Replaces hardcoded color hex values with their equivalent
values from Codex, via the "mediawiki.skin.variables" system.
Bug: T366197
Change-Id: Ia929a1a8d6351222acb454c8ec750e920ae6d072
The following rules are failing and were disabled:
* modules/ve-mw/tests:
* implicit-arrow-linebreak
Change-Id: If857233c0de24c8cf619dbb1347ebb375f3ab1ba
I'm going to assume the order in production with Chrome, as asserted
by the unit test, is the preferred order whereby negative numbers are
intended to be prepended before the positive numbers.
This came up in I6ecbd5743f3e, where this was the only unit test across
MediaWiki core and WMF gated extensions, that fails in Firefox.
It is reproducible locally with plain MW core + VisualEditor as well.
Bug: T366299
Change-Id: I6f8546e6e604cbb41e11bd2b59f8b5f19350c676
Previously, it was possible to close a dialog with active edits by
pressing the "<" button or pressing escape. A change was made to confirm
the user's intent before abandoning their changes, see Ia8935b5b1acb
This patch fixes a bug where the user's intent is always confirmed while
editing a template, even if the user has made no changes. This was
because for technical reasons we trimmed whitespace before making a
comparison with the new template case, but that caused the comparison
with the edit case to always fail because existing templates are padded
with whitespace.
This could have been solved by moving the trim operation into the new
template flow. This patch would still have been necessary to prevent
a bug if the default value had trimmable whitespace. I have opted to
keep the whitespace behaviour for edits for consistency.
Bug: T334513
Change-Id: I7b3370c86df67c36fc63a1f1d0e7004a098a1950
