Created following test cases:
Scenario: I am a user that wants to re-use refs in VisualEditor
-should display existing references in the Cite re-use dialog
- should display re-used reference in article with correct footnote number and notification in context dialog
- should display correct ref content and name attribute for re-used ref with existing name attribute
TODO:
- run several rechecks to observe flakiness issues
- add remaining test cases (copy paste & cut paste)
Bug: T356858
Change-Id: Ib1b64c44b21471404a7c51752fb5899119b4b533
There is much more to test, but it's a start.
Intentionally build as pure unit tests to make them as fast as
possible.
Bug: T354215
Bug: T358652
Change-Id: Iae1a8086b8f2b9e5b11e0117bd3f19fdaa087df0
The first two files have been added to the root modules/ directory
via I487095d in 2015. No problem.
Many, many more files have been added via I000b453 in 2022. It's
really hard to tell what is what since then.
I'm not absolutely sure what the naming convention for this folder
should be. Could as well be "localized-styles/" or just "Parsoid/".
Bug: T156350
Change-Id: Ibcf8c7a6db5400ed8a9811244a070e03ff372a39
The information read from the …cite-tool-definition.json files is
effectively user input, even if only interface administrators can
edit it. Usually we carefully validate user input. But as of now
this code starts failing with all kinds of uncatched errors.
* An entry with no name, an empty name, or a name that's not a
string will cause all kinds of undefined behavior.
* An entry with an empty title results in an invisible button.
* A missing message results in a technical <…> placeholder, even if
the name is usually a sensible fallback.
Note that hard-coding titles as plain text strings in the ….json
file was already possible.
Change-Id: Iddcedbe859e86ac4c3f79a53d36237daff86c0db
The message was part of the original patch that introduced the group
feature in 2009, see https://phabricator.wikimedia.org/rECIT75004e33.
Notice how there was never a test scenario for this message. A test
was added in 2020 via I07738cc.
The message appears only in a rare edge-case when a group is entirely
unused in the text, and only when the group is not empty. The shortest
possible example is:
<references group=g>
<ref group=g name=a>a</ref>
</references>
Just adding something unrelated like `<ref group=g>x</ref>` to the
text changes the error message. Now the group is "used". But this
notion is confusing to begin with. References can be part of a group,
and we can use references, but we can't use groups as if they are a
separate entity.
A better error message already exists.
Notice how this special error message doesn't appear anywhere in the
Parsoid code path. That was already using the other, more generic
error message.
Bug: T269531
Change-Id: I63f663d76e45e6c3d664f145d9a564ee00ff53cd
This is about the error message that currently says:
»Cite error: <ref> tag with name "a" defined in <references> has
group attribute "" which does not appear in prior text.«
This is a special error message that appears only when a group name
does not appear anywhere in the text. In all other cases a simpler
error message is shown:
»Cite error: <ref> tag with name "a" defined in <references> is
not used in prior text.«
While the first error message is not wrong in the edge-case
described in T269531, it's very confusing for a multitude of
reasons. For example:
* There is no group attribute in the wikitext.
* Just adding something completely unrelated like `<ref>x</ref>` to
the text shows the other error message.
The reason for this behavior is that the assumed default is an empty
`group=""`. The error message changes the moment any other <ref> in
the same group appears in the text vs. when the group is entirely
unused.
We can probably remove this error message entirely, but should at
least not use it when there is no group.
Notice how the Parsoid code path was already using the other error
message.
Bug: T269531
Change-Id: Ifa2e97254f4cda72233a057d8760fb1116143552
Missed while merging Ia0a52cc7459d4e985349e8c0e4656f68e25d8afb
into Iaee1dadcc19a70c27839d0d27dfa6a07a70fb46b
Change-Id: I0a429a52bcf04bac9cc63cb5856f4c8fdd06b1fa
This didn't mean what it looked like: `||` has higher priority, so an
undefined elem would not result in an empty string.
Change-Id: I1e361842f060815b04802a1ab8f077faa1a8bc6b
Some of the annotations were used in a way that confused jsdoc. This
cleans up redundant annotations and uses more canonical tags.
These changes cause all classes to now appear in the generated pages.
Includes linking to external docs.
Bug: T358641
Change-Id: Iaee1dadcc19a70c27839d0d27dfa6a07a70fb46b
Not perfect, some classes are missing. But it runs successfully and
generates some docs already.
Bug: T358641
Change-Id: Ie10e48ab9ac80e4969a152562a746cb54c7ec0e4
These tags are 10 years old. Current documentation generators don't
need them.
Tagging something explicitely as being a @method can be useful in
an interface where the elements are initialized with e.g. `= null;`
instead of having an implementation. But we have implementations
here. Sure these are methods. No need to say that in the
documentation.
Also removing a comment that's obviously a copy-paste mistake from
what was the ve.ui.MWMediaSearchWidget back then. See Ib244ff6 and
before.
Change-Id: I7df6c789d10fd89e7fe97d56c942fd22c56d8458
This reverts commit 0566a495f3.
Reason for revert: Merged too soon, while discussion of the whole
approach is still ongoing.
Change-Id: I2d3d6455cd4ea12067e2020f6b41cfbb4672bbb5
This was added in 2006 via commit eb3a3f78, see
https://phabricator.wikimedia.org/rECITeb3a3f78
Hard to tell what happened back then. It's obviously not needed any
more, as proven by the tests. I mean, even if there would be an
extra newline character, it would be irrelevant at the end of an
<ol>…</ol>.
Change-Id: I5715cd9f31ac7ef86c1ea227642336ae71684291
I always found the name a little ambiguous. The fact that it outputs
an actual HTML list and not just some "references" – whatever that
means – is relevant, in my opinion.
Change-Id: I0d169455c8d2b42d62da4dccb8376c09fb6902bc
It's fine to copy attributes directly from the reference node rather
than go through the specialized model object.
Bug: T336417
Change-Id: Idaca192137dc762ddced2ee8446a7d838f97e317
This was slightly overengineered ever since I4b1f890 and slowly became
more and more complicated over time, notably when withConsecutive was
replaced in Icb951b4. Turns out this was never really needed. It's
impossible to get more than one tracking category from this code path.
While we might add more tracking categories later that will most
probably not happen in this code path.
Change-Id: Ie32d17bac8d3518c985b18f83a846c3fb2bd053f
Begin a QUnit test module for the reference model. Tests demonstrate
that a new ref and a normal ref reuse from the full document both
behave as expected.
Bug: T336417
Change-Id: I1337806d41b50329ba971c8e68e1a62b52cc9a52
Implemented the test case as described in the ticket.
Deviated from ticket's approach for creating a new page by manual creation instead of API,
to verify the end-to-end functionality through the interface & ensure the entire proccess works seamlessly.
Bug: T353439
Change-Id: I8f863ae0bd8fdb1fb0f1b103d98ba9f2306f3df2
Make sure that we're waiting for the page creation to finish, and
assert that the API request was successful. This is mostly a
diagnostic improvement to help debug flaky tests.
Bug: T355602
Change-Id: I398cffa724e9b6d733df46676478cc98dccd884d
