We'll update this before 1.36 is released, unless we get Parsoid
integrated "properly" before then.
Change-Id: I92d8555b1f5dc121c5f596b5cb6d59414280388f
If we call getBoundingClientRect() while the 'transform' animation is
still ongoing, it's going to return values reflecting the transform
- that is, the rect will be partially offscreen - which will trigger
our code that runs the animation again.
I don't know why this wasn't a problem on iOS 13.3 and earlier. Either
the timing was slightly different and the 'transform' animation was
able to finish earlier, or getBoundingClientRect() was buggy and
returned wrong values that conveniently worked right for us.
Bug: T259321
Change-Id: I6be0ddaeb6df54295fb14c45ba15fee41d61e33f
The MWParameterSearchWidget that shows a list of all available
template parameters displays the (human-readable) label and
description of each parameter (both given via <templatedata>), as
well as the parameter's internal name and aliases, if there are
any.
This turns out to be non-helpful in the majority of situations:
* When there is no <templatedata> yet, there are no labels.
Instead, the names are used as labels, which means they are
*all* identical and everything is shown twice.
* The same happens when manually adding an "unknown field". Simply
start typing, and you can add parameters with any name. What you
type is shown twice (actually 3 times, 1 time in the input
field, 2 times in the result widget).
* Many template parameters are already nice, human-readable. Even
if <templatedata> exists and specifies labels, these labels are
often identical to the names. There is no need to come up with
something else if the name is already good enough. (Exception:
Localizations, but these are rare.)
Furthermore, this is a *search* result widget. The pretty much
only reason the names and aliases are shown is because the user
can search for them, and needs to understand why a parameter was
found. This still works fine.
For comparison, when a parameter is required you will *never* see
it's name, because the parameter is always there, and never shows
up as a search result.
Change-Id: I6b1dca1c94b2c496930b5bfdfe1c6f76898faa2a
Parsoid always enables `<ref>` processing, but our Cite extension
implementation tries to fetch $wgCiteResponsiveReferences, which won't
be set if the Cite extension is not installed.
Change-Id: Idde8af07e5bf40983b2ec878ebf70aabb522a800
(cherry picked from commit 0ca4ae6908b626d34f8445d9048342378d0e3c23)
DOM attributes are not arrays, and so don't have Array#forEach.
Fixed regression introduced in 4545f53245.
Change-Id: I1f0f44747a0f8a376c1fb7cbb8862c096a9d1dc9
Currently we always register VE as a Beta Feature, and then
expect users to use $wgHiddenPrefs to hide it, hackily.
Also, set this new preference to false so that 3rd party
wikis don't show the BF by default.
Bug: T254349
Change-Id: I92fe3d44bb4d762ca7b1bc693b7d2e74367c84ec
Items which are invalid titles will still get discarded if
the gallery is edited, but this is better than crashing.
Bug: T260584
Change-Id: I5dc20c233fd9ab41bdf48531829bddca2c5b25df
getDefaultMessageText() returns false when the message doesn't exist.
It was incorrectly treated as a string by this code.
Follow-up to 3ec5e04a37.
Change-Id: Ib94a30697bd20133e46cbd31c14caf5f0c4169dd
New changes:
c9e4bc776 Use placeholder name as aria-label
37a4922a7 Localisation updates from https://translatewiki.net.
55a0d0488 Teardown the completion widget when menu is hidden by user
Bug: T253590
Bug: T259277
Change-Id: I7d6e19c45f1dc87d1f4127c75c4812aadd5c5cf5
In MediaWiki core, Ic418c23a740 moves mediawiki.page.startup into
mediawiki.page.ready, leaving an alias behind. Once that change lands,
this change is safe to land as well to avoid the indirection and so
that the core alias can be removed swiftly (VE is the only user).
The dependency on mediawiki.page.startup was originally added in
I494b364b485e6 to make sure that accesskey tooltips are computed by
mediawiki.util, before VE initialises (this happened via mw.util.init,
which at the time was called from mediawiki.page.startup.js),
This has all changed a lot in the years since then and might not
actually be needed any more. If that's the case, feel free to remove
the dependency instead.
Depends-On: Ic418c23a7400abba22fd07b17f173d3c5f1d1d10
Change-Id: I250b38a836f28bfb440f19282a9677977f30c615
Set the 'forwardCookies' flag if the wiki is private (not everyone is
allowed 'read' access).
Bug: T260201
Change-Id: I0b958e8b75c04e4a27f50f91276be221a5b1404d
The interface has enough space for 2 or 3 lines of text.
(On mobile, the button has only an icon and no label.)
Bug: T260074
Change-Id: I50b08029f843e91d10b8c81985f6dfacbb96c8e7
New changes:
c5496ec1e TargetWidget: Use a white background, not transparent
4efa1529f Support headers in CompletionWidget
fe0ffe6e4 Update devDependencies
Bug: T252084
Bug: T259811
Change-Id: Ic60aaafb1d07db30c72832414e68bba71f5e93df
New changes:
7cd74c97d Localisation updates from https://translatewiki.net.
84640d0a8 Localisation updates from https://translatewiki.net.
ec14afa43 Update OOUI to v0.40.1
Change-Id: I1a64b9aea121db8340b9d136fb41cb69f6be6d81
The 'checkbox' part of the edit form is now allowed to contain
non-checkbox form widgets, but these are not yet supported
by VisualEditor. Until they are, this skips them entirely
in order that no broken form field be shown.
Bug: T259546
Change-Id: If62c11b174df235be611b9d32eb28e4759ba5f66
