the former is no longer present
note: i assume the style is still needed, I have
not tested
Bug: T255718
Change-Id: I4e7851362fc0d64097aeff5ec1535f8fe7480682
Like transclusions, extensions can contain nodes of other types. This
hasn't been an issue because the legacy parser doesn't generate content
with these annotations. But, moving forward, as Parsoid becoming
responsible for more extensions. This is the case for the new ImageMap
implementation.
Matches I95767e466803f0744b6626204a0a3a1514fff174
Change-Id: I6ff81a01207e2734090c626b177e5f4d10bb6d61
New changes:
c53286843 Make NodeWindow a standalone mixin
a787fbef1 Update OOUI to v0.40.4
0d74538ee Refactor dialog logging out of ui.Command into ui.WindowAction
ea55ede8d [BREAKING CHANGE] Improve structure of special character definitions
Local changes:
Fix output of fetchSpecialCharList to match new format
Bug: T264146
Bug: T264690
Change-Id: I2a28bb9c3e54cb5f9308ab361dee99bc801b467a
A language code is better than an empty string.
The string would be used in the LanguageContext to
describe an annotation like <span lang="en-fakeVariant">.
Change-Id: Ibc18c238d6216927447ca26f336e9d973c6b93eb
Reference images are moved to Cite and used by Citoid.
Bug: T170919
Bug: T171292
Depends-On: I02041246dda1b3d3ad1bcc0b014fa022e8259b62
Change-Id: Id97659ed1fa64a1223a8957fefaf2a149edd0e9c
New changes:
cb4613044 FindAndReplace: Always highlight results when opening
cf480dbb6 ElementLinearData: Remap annotations on nodes too when sanitizing pastes
705743230 ElementLinearData: Remap annotations on moved meta nodes too
16be2c262 ElementLinearData: Remove moved metadata too when removing metadata
6d51882e2 ElementLinearData: Deduplicate annotations when sanitizing pastes
Bug: T191487
Bug: T259730
Bug: T262877
Change-Id: I0918ad9833c15998b1696ec40c1681c0d8f14236
I'm not 100% sure, but this looks like a copy-paste mistake to
me. Something like this (a subclass modifying the base class)
is not done anywhere else.
Change-Id: I24677c2deb721b68d1b534f1569c925b386d4d3d
The 'mwSignature' command replaces the selected content with your
signature. So basically, if you double-click this node, it gets
deleted and an identical one is inserted. This is useless.
I think I added this when this class was inheriting from
ve.ui.MWTransclusionContextItem, to override the command that would
open the transclusion dialog, but even then this should have instead
been `null`.
Change-Id: Id4492e36e9d89001df655e48b528d07eb608289e
These constructors only take a single argument, so the api config was
being ignored and the input would fall back to the default `new
mw.Api()`.
The order is changed so that the "api" config is merely a default,
and can be changed by whatever comes later.
The UserInputWidget currently doesn't accept an "api" config. This
will be fixed in Ifb1dd9d. But this is not a blocker. Merging this
patch here before the other won't have any consequence. It will just
continue to ignore the "api" config. ;-)
Change-Id: I15c35216c717576c6767927cac06ef72198fc95a
EditAttemptStep requires an integer, and just getting the value of an
input is always a string.
Bug: T261664
Change-Id: I57e76857086474365124b5b016902211b0e63166
The input field becomes a title autocomplete, showing small preview
images and searching only the File namespace.
This is consistent with how TemplateWizard behaves when editing a
File parameter.
Bug: T260886
Change-Id: I7a114e279436ec1ff6f7b8ab66443138ab12637f
This patch starts using watchlist related values from ApiEditPage
results instead of updating the "watch link" based on whether the
checkbox was selected or not at the time of saving the article.
This change does not depend on T261030 and can be merged without it
but T261030 needs to be fixed or temporarily watched items will not
display the right tooltip when hovering the "watch link" or star icon.
Bug: T260434
Change-Id: I2c844223620d7d28f36a0cd8ae3dee4b0c8ae5bf
Remove angle bracket from the url. The closing character is breaking
the hyperlinking and is not necessary anyway. Also bypass redirect.
Bug: T261126
Change-Id: Id9839623f5f77766042a0df0dfdd5f93d6faf625
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
