Same as in I7e82e03. The extra "shield" element was added in
2013 (!), see Ib244ff6. Back then we couldn't use the CSS property.
But nowadays we can.
Bug: T360034
Bug: T367030
Change-Id: Ib41e062491e65eabc8a52facefe283ba04ce16ff
To make sure also the parent gets a name even if it is not re-used
we need to iterate the list of reference to see if there's at least
one child that matches the parent.
The rest will be taken care of by getUniqueListKey that makes sure
that the matching temporary names will result in matching literal
names.
TODO:
- Write a ve.dm.Convertor test which shows the auto-name being
added.
Bug: T367031
Change-Id: I6ef42c8ffc8a4ff9224bfb2a910682d2c44f0dd2
I believe this was a mistake in the previous patch Idd57997. Using
only the .text() of the parent reference is not sufficient. Think of
a reference that contains a <math> formula or – even worse – is
nothing but a <math> formula. The preview will be empty in this case.
Click handlers in the preview need to be disabled. It's only a
preview.
Bug: T367030
Change-Id: I7e82e03ecfeb4e9cf132985684cff5e191506307
This makes it much easier to deal with the internal auto names
used on new elements created during one edit session.
We're ignoring the correct generation of the auto name literals
for now.
Bug: T367031
Bug: T367030
Change-Id: Idd579970cb64500dac27053213e9b116f23b6d76
Also removing the weird hook code that was only there to make sure
JS finished loading afaik and then was copied over to other parts
of the codebase.
Change-Id: I90185b14de69bf3f4b6230b9a87c7eff261e72b4
With this change the <ol> is added after the inner list of <li> was
parsed as wikitext. In other words, the outer <ol> is now raw HTML
and not sanitized any more. This is fine because it's generated via
code. It doesn't contain any user input.
You might ask how it is possible to parse "invalid" HTML that
contains a sequence of <li> without the outer <ol>. This is fine
because the wikitext parser doesn't care about the nesting structure
of HTML elements. This is done later by Remex (Tidy). But Remex is
never called here. What we care about here is that the wikitext
parser sanitizes the individual HTML elements and their attributes.
The <ol> doesn't need sanitization.
This will make it possible to use reserved data attributes for
T196828. A bazillion unit and parser tests prove that this change
doesn't have any unwanted side-effects.
Bug: T196828
Bug: T239572
Change-Id: I0a9d419f48cad5ddb7251c8fdd2cf9506649436b
I'm importing the current keys from the Popups extension without
renaming. After that's done keys can be renamed and we can take
care off the fallback solutions.
Bug: T363156
Change-Id: I788c16c5bddc0df7f00dbbc39625b9adaa5bf184
I'm still not sure what causes this to fail in CI locally they
are running fine. In the CI it seems from the recordings, that
Citoid is not loaded when these tests are executed.
Bug: T366383
Change-Id: Iee9e4dd04e08fd3ddfa77409d037ec80f84ead3e
This patch adds 'mw-cite-backlink' to the linkback span for both
named and unnamed refs. This requires us to add a span wrapper
for the unnamed refs case.
Verified in local testing that this causes aria attributes to be
added to the linkback tags in Parsoid HTML.
This should likely fix other gadgets and code that rely on this
class name to do their work.
Strictly speaking, this is a breaking change since we add an
extra span wrapper for the unnamed ref backlinks which *could*
break anyone using a li > a[rel="mw:referencedBy"] selector.
But, given the specificity of the a[rel] selector, the "li >"
part is unnecessary and might not be used. So, if we wanted to
push our luck (and break process), we could get this in.
Alternatively, we could:
- do this in the the read views OutputTransformPipeline.
- do a real major version bump -- we would be exercising that
functionality and have to fix and implement any missing pieces
that may have broke as part of the RESTBase sunsetting.
- not add the span wrapper and fix gadgets to explicitly look for
both named and unnamed refs with their selectors.
Bug: T328695
Change-Id: Icbd325ebd12cb42186c5b5220dc016835eb18b64
This should make sure events are added to the corresponding UI
elements and reduce flaky test results even more.
Change-Id: I2317321912945ef20f8f49405b54fddd65c618d1
Page property is removed immediately since $wgCiteBookReferencing has
never been enabled in production.
Bug: T239989
Change-Id: I6252fcf1485994244dca40470cc5955e8d4f6917
This adds the 'reference-text' class where Parsoid added
'mw-reference-text'.
If we don't care about the "mw-" prefix, since there are very
few wiki and code references to 'mw-reference-text', it might
seem like we could update all those references and rip out
'mw-reference-text' from Parsoid output.
But, Parsoid HTML is also exposed via the REST API which means
there are likely many users out there analyzing Parsoid HTML.
https://github.com/search?q=%22mw-reference-text%22+NOT+language%3AHTML&type=code
says there are 512 references to this string - so looks like
we are probably going to rely on a major HTML version bump in
Parsoid in the future and then rip out all the duplicate
classes (mw-ref, mw-references, mw-reference-text OR
reference, references, reference-text).
Bug: T328695
Change-Id: I04b18ac75863a0e3e61bdd47b34508e5547dc872
