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
This can be quite confusing:
* A node does have attributes. One of the attributes is called
"refGroup", another one "mw".
* mw contains a JSON structure with just a few elements, most
notably a "body" and an "attrs" element. These reflect what was
originally written in the wikitext.
* mw.attrs reflects the original properties a.k.a. attributes from
the <ref …> or <references …> tag.
Deleting mw.refGroup doesn't do anything because the attribute is
called <ref group="…"> in the wikitext, not <ref refGroup="…">.
You can actually see this bug in action on all wikis: Go to a page
that uses references in non-standard groups, e.g.
https://en.wikipedia.org/wiki/Historic_Cherokee_settlements
Start VisualEditor. Find e.g. the [notes 1] reference. Edit it
and change the group from "notes" to "General references". Click
"Publish…" and "Review" your changes. The visual diff works because
it apparently uses other information. The wikitext diff is empty.
This is also what's saved: nothing. The edit is lost.
Bug: T359943
Change-Id: I798605d2fd60a6b8f317ec85a4e4d08fd245e084
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
I find it very helpful to use the name "mwAttrs" specifically for the
mw.attrs thingy that contains the original key-value pairs from the
wikitext.
An alternative is to use ve.getProp, which is helpful in other
situations.
Change-Id: I3edf0dfe5b9629fcda0bf8cb3b734215377a5c77
* reads the new attribute extends from wikitext
* saves it into the reference model
* adds a message to the VE popup of an extension as a first demo
* tests will be added in a separate patch
Bug: T247922
Change-Id: If4d309c4678022642f39e21565950dc45e557d47
This is a bit of an abuse of the originalDomElementsHash property.
In future we could add a 'uniqueId' attribute, but this would need
to be ignored in a few places in core.
Bug: T299378
Change-Id: I7d1eb362aeb74ba93f5225330226a95535746b92
In Ifb0ba3caf8d we removed this reference equality check and replaced
it with a deep object comparison, however due to the fact that
hashes for MWReferenceNodes were simplified in I8c26686d7b to
improve visual diffs, this resulted in a overly simplified comparison
that couldn't distinguish references with the same "name".
Instead do a deep object comparions of the standard node hash object.
Tests added in Ia0bbd40528 assert that this doesn't result in the
regression that caused T296044.
Bug: T296086
Change-Id: I7b37fb54e14bfe28a07f722a2c45fd4e4a2d44f2
Previously we checked the elements were reference-equal
which is fragile and breaks when linear data freezing is
enabled in debug mode.
Change-Id: Ifb0ba3caf8d3e5a67c9694358cac12cc412fe723
This means that all reference nodes are treated as comparable
in the diff (provided they are in the same group) so will
not show up in the article diff if their index changes.
Changes to the reference list are already handled separately
by the visual diff.
Bug: T170235
Change-Id: I8c26686d7b2fe3bf91af7d4dcab1caf3247dbe47
* Add it to CE HTML, for compatibility with site styles.
* Add it to DM HTML of newly created references only. Existing
references just use whatever classes we got from Parsoid, to avoid
unnecessary DOM changes and dirty diffs.
Bug: T265930
Depends-On: I61a2132f3876e2d9567d985358f51eb51c479813
Change-Id: I9d6856f03071c09617b8ae7db938135a3e30fe8e
If a ref node is highlighted as changed because its index
has changed (e.g. because an earlier reference was inserted
or removed), describe this more elegantly.
Bug: T170235
Bug: T171377
Change-Id: I2513bb82099a92529516e4e217e61a2d0a2dd43b
Recent changes to setRoot in ve core (719f8c667) cause unroot to occur at a
point we weren't expecting, when adding a new reference.
Bug: T163267
Change-Id: If02ea08bb8b6db3be41d51ab44ce2a74cfe07914
