A notice already appears and informs the user of the visual editor that
they're not logged in if their session has ended. Showing an additional
error dialog informing the editor of this when saving changes is not
needed.
Bug: T345975
Change-Id: I20a904dbc6d3c2f0d08e4ceea27e35ee1b65bb71
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
Same as in If6c7e85 in the TemplateWizard codebase. [a-z] is already
part of \p{L}, and [0-9] is part of \p{N}.
Change-Id: I8008ac7e504739b8f4b5fb5dd732b0deca20cefc
The ruleset wikimedia/client-es6 already contains
the ruleset wikimedia/jsdoc. So wikimedia/jsdoc
doesn't need to be declared.
Bug: T365047
Change-Id: Ibc13c9bf4bbbe36d5c8296372f59cc13a0c0940b
The promise is supposed to return a function that can be used
to lazily generate the visual diff, not the visual diff itself.
This was broken when switching to arrow functions.
Bug: T364635
Change-Id: Ifa971333aa22af346bb62d031dc20afc8979992c
This line was introduced by If59979f.
This action is only invoked from the 'safe' action when the dialog mode
is 'info' - uploads are under 'upload-info' instead - so I believe we
shouldn't end up here from an upload and whatever condition this was
guarding against is no longer a concern.
Bug: T362015
Change-Id: I6a6551eab3fb698a6ae781be4623b48e4b4c7edb
They generate a lot of false positives in this extension.
Since this is client-side code, the worst that could happen is a
browser tab hanging, not any real security issues.
Change-Id: I177cfa7e57a6b7b528d558d2cba076e85fd0271f
Follow-up to
I2495fe32c2d540be50450d715b049173f2f8727d
Done with the help of Matma Rex at Wikimedia Hackathon 2024.
Bug: T361103
Change-Id: Ica328233cb6172277e66d2341cfb53f87f8aff67
* Remove need for manual hacking of sub groups via "msg" strings
carefully prepended to every assertion.
* Improve CI details, by reporting the specific case that failed,
and local dev via ability to re-run each case, and reporting names
directly in the HTML Reporter and CLI summary.
* Reduce need for assert.async() and tracking of callbacks, especially
to improve failure details in case of Promise rejection.
Current logic was likely to cause a confusing timeout instead of a
clear failure if the promise ends up rejected.
QUnit propagates these as part of awaiting and asserting the test
closure's promise value (as async fn) automatically.
This approach also avoids the pitfal of a falsely passing test
when an assertion inside a done() handler was never reached.
* Use modern for-of where possible to remove need for closures and
arrow functions. Thus reducing complexity of test code, where
complexity should be kept lowest to avoid false confidence.
* Use plain for-in instead of overly complex Object.keys().forEach().
Change-Id: I934a266e75e64371081f104cfb867fb2c282c84a
This is not great, but it's a start (and unblocks other pull-throughs).
New changes:
c401efc98 build: Replace jsduck with jsdoc for documentation
16ba162a0 JSDoc: @mixins -> @mixes
9e0a1f53b JSDoc: Fix complex return types
449b6cc0f Prefer arrow function callbacks
1539af2c8 Remove 'this' bindings in arrow functions
b760f3b14 Use arrow functions in OO.ui.Process steps
57c24109e Use arrow functions in jQuery callbacks
9622ccef9 Convert some remaining functions callbacks to arrow functions
f6c885021 Remove useless local variable
1cd800020 Clear branch node cache when rebuilding tree
Bug: T250843
Bug: T363329
Change-Id: I0f4878ca84b95e3f388b358b943f105637e455f9
