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
* The Minerva repository has a ".mw-ref" style which is Cite-specific
so that makes be wonder if the expectation is for this to be in
that file instead. That would be a really simple fix and be attached
to the rule for sup as an extra selector.
* But, it seems like Cite extension is the right place for this.
* Found while trying to test Cite rendering with MFE.
Notes:
* This mirrors the style added in
Ieb91c1251839ff4bb54451aae69af9fb88322219
Change-Id: Iae1d391ef11e53110bfb758d45a0fbdf2addf62e
Also simplify the @covers annotations while we are here. The class
is really simple. There isn't much that can be covered acidentally.
Change-Id: I105f4ea6d6beb119d1557a32b691e9eda1b8085c
This is a direct follow-up for what I started in I3c9b9bb. Again all
this does is moving existing code around. The separate this.deferDoc
property is never used anywhere:
https://codesearch.wmcloud.org/search/?q=deferDoc&files=%5C.js%24
Instead I store the deferred function directly in the target property
this.doc and resolve it when needed.
Note that the concept of a parentDoc still exists. I tried to make
this as obvious as possible via comments and by arranging the code
accordingly:
1. A lot of code calls setDocument which directly sets this.doc. The
parentDoc is never used in this case.
2. The parentDoc is only needed to auto-generate the (empty) document
for the reference when a new reference is created.
That's also why the existing code always calls the constructor with
the parentDoc, even if this ends being unused in many cases: It's a
simple fallback.
Bug: T363096
Change-Id: I7874f187b2b397ed511b695ca9ff95838fcff302
mw.attrs does have a special meaning in this code. Together with
mw.body it reflects 1:1 what was written in the original wikitext
in the <ref …> and <references …> tags. Let's avoid using the same
(or almost same) variable name for other kinds of attributes.
Bug: T363096
Change-Id: I3e599ab910b9639e121f9b9d532b0f57f08f1e73
Introduce a static method so we don't need to copy paste code.
Note that the static method still largely duplicates what the method
.buildIndex() will later do. Both loops iterate the reference groups
and the references in each group. The main difference is that the
"is empty" check stops extremely early the moment it finds any
non-empty group.
That's also why I'm convinced it's not worth caching the result.
I benchmarked it and it's nanoseconds. But there are more reasons:
The non-static .isIndexEmpty() method is currently only used when
Citoid is active the same time. Which means the cached result was
entirely unused on installations without Citoid.
Bug: T356871
Change-Id: Id5c4295086bc977ef52ad141be9962d2eecb1bcc
Cite tests are blocking Citoid patches, by failing in that
environment.
TODO: To be reverted once the incompatibility is resolved.
Bug: T364382
Change-Id: Ie8eeac79966ccb46389e4f9aaa4620e9bd75cc00
No need to create an expensive model here when all we need is a
single attribute.
Note this code is still behind a feature flag and not running
anywhere, except on the beta cluster.
Bug: T247922
Change-Id: Iea48837213b72a8d0f4b3cc9d9688d9a08315509
The two are different:
* CiteReferencePreviews as specified in extension.json is a feature
flag that allows us to disable the feature entirely. It could be
named "CiteReferencePreviewsFeature" or "CiteEnableReferencePreviews",
but renaming a feature flag that's already in use is hard.
* The client-side flag tells the JavaScript code "you know what, it
was kind of a mistake you got loaded, please stop". This is because
we can not make all decisions before we register the ResourceLoader
module, e.g. if the user has certain gadgets enabled.
Adding the word "Active" is not a huge improvement, but at least
makes the two different now. Suggestions welcome.
Bug: T362771
Change-Id: I0f6a911df8772616ac50c1301f402f77dbe32089
