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
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
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
Follow-up to
I2495fe32c2d540be50450d715b049173f2f8727d
Done with the help of Matma Rex at Wikimedia Hackathon 2024.
Bug: T361103
Change-Id: Ica328233cb6172277e66d2341cfb53f87f8aff67
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
Despite its generic name, this class exists just for the
template dialog and does 3 things:
1. Provides generic accept/reject override messages
2. Provides a new function signature when the prompt
and success callback are passed
3. Focuses the delete button
(1) and (2) can be provided by a local helper function.
(3) should be implemented upstream, although given this
was done to prevent users taking destructive actions
accidentally I'm not sure why this should be overridden
here.
Change-Id: Id5aa018310eded7a3552a182d19ca16b040abcbd
For the invalid border color we'll use the current border error color.
With CSS custom properties on the horizon, we'll easily replace them
consistently in the future.
Change-Id: I1ec266e90a974cf79576ee7db6287ea4eac94656
This patch promotes a consistent design decision across projects in
MediaWiki core, extensions, and skins. The darker red color meets the
W3C Web Content Accessibility Guidelines (WCAG) at Level AA that text
or images of text must have a contrast ratio of at least 4.5:1 (or 3:1
for large text).
Bug: T343239
Change-Id: I0f8db861b029c61d524416379a1a842f5137c8cb
