This isn't the ideal solution since it doesn't exactly match the
rendered reader view, but it's a reasonable workaround and an
improvement on "undefined" numbering.
Bug: T247921
Change-Id: Ic0d88123d50e2fcb7f25e897280dbfdb6d494501
MVP implementation for adding a warning when editing a reference
that's the extension of another. In the current approach we're
just using the elements .text() like we do when you create an
extended reference.
Bug: T247922
Change-Id: I2fc574152059937b4aa3fc25ee486d363cc809d5
We only need to set some values that are needed by the `insert`
action triggered that then handles the insertion of the ref.
The form to edit or add a reference will never be visible
in the re-use workflow. No need to update that message then.
Change-Id: I710862bdc1bde6a8ce663d863d721cbf075494f0
Includes renaming the method so it's more clear what it's doing.
As preparation for adding the extends warning to the edit pane and
to allow easier identification of parts belonging to the edit
workflow.
Change-Id: If84c5dbdee19c0ebc0a28b50dda93fef3f558c6e
With this patch, we show reflists in a hierarchical view with subrefs
listed under their parent.
TODO in follow-up patch: numbering of subrefs is still incorrect.
Change-Id: Ia82658af72caebd29241b9bd329d236ddc3f1e6d
Pure refactor which shouldn't change output in production. Switches
to interfacing with MWDocumentReferences to get refs in index order.
Temporarily suppresses any subrefs, we only show top-level refs.
Bug: T247921
Change-Id: I9c8347b064173027f436722c87e15e0381c958bd
C&P mistake in the original implementation. Otherwise we end up
with an undefined in the name.
Bug: T362347
Change-Id: I5c6957ca9fc81e6a5211aab050025eea5d0addbe
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
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
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
We can re-use the existing this.deferDoc property to achieve the
same. There is apparently no need for a separate "parentDoc"
property for anything else but what can be seen in this patch.
https://codesearch.wmcloud.org/search/?q=%5CbparentDoc%5Cb
And no need to keep neither the parentDoc reference nor deferDoc
callback indefinitely. We can drop it after it got resolved.
This really just moves existing code around without changing
anything.
Bug: T363096
Change-Id: I3c9b9bbdff29a3f35d5a0710b48ca59bf592c6ab
These aren't used anywhere:
https://codesearch.wmcloud.org/search/?q=%5Cbset%28ExtendsRef%7CList%28Key%7CGroup%7CIndex%29%29%5Cb
These setters are reaching into internal details that currently
aren't ever modified from outside of the class, and shouldn't.
If it turns out we ever need to modify one of these we can easily
re-introduce setter functions, but probably give them more
meaningful names.
Bug: T363096
Change-Id: I2c9efc114bdc110a29b8d7fb48ea8c1814cdeb21
Note this is only a bandaid patch that avoids the failure in this
place, but doesn't solve the fundamental problem. It appears like
the data coming from Parsoid (in internalList.….firstNodes and
internalList.….indexOrder) is somehow out of sync, and one of the
numbers in the .indexOrder array points to an element in .firstNodes
that doesn't exist (any more?). I don't know why.
Bug: T351550
Change-Id: Iaa4c748462d90d7783edb89713b61ffff6d70765
The search index is really only used in a single place, in the
buildSearchResults method at the very bottom of the class. I find it
more obvious to understand what's going on when the places where the
search index is populated and used are as close together as possible.
This again really only moves existing code around without actually
changing anything.
We can also drop the extra "built" property and use a special null
value instead. This is possible because we know the only consumer of
the this.index property and can guarantee it can't get confused by
the null.
Bug: T356871
Change-Id: Iaddb3b16b3aa776f89fca2bf0350cce9b6bb1a23
This turns two methods with side-effects into more pure functions
with more obvious input and output. buildSearchIndex rebuilds the
internal search index from the internalList. buildSearchResults
filters and creates the result widgets the user will see.
This patch really only moves existing code around but doesn't change
anything. Except that this.built is set before onQueryChange is
called, not after. This avoids potential endless loops in case
onQueryChange happens to trigger buildIndex again.
Bug: T356871
Change-Id: Ib80a2dcb85779d64bec53caf90c49879d0ea2258
I find this particularly confusing because it makes it look like this is
an array. As a reminder, while empty arrays are false in PHP they are
not in JavaScript. An extra `if ( array && array.length )` is really
critical. But this is a string. Empty strings are false in JavaScript.
No problem.
This was originally written in 2013 via Ib244ff6 as a pure .length
check. The duplication was added a year later via Id401d97 for an
unknown reason.
Bug: T356871
Change-Id: Ied335f170a9a0a7bbc8c8fd12f95b6902f401bbf
Note these are more meant as regression test to better cover what's
done in other patches. Everybody should feel free to delete a test
when it gets in the way. I marked a few especially fragile places
with respective comments.
Bug: T358652
Change-Id: I7844907fe3ef4f3439717381b4ecdac9e2d0a825
This CSS exists since I2ab47e7 from August 2014. The original idea
was to dim the default "General references" when you edit a <ref> or
<references> list in VisualEditor.
Steps to reproduce:
* Start VisualEditor.
* Edit a <ref> or <references> list.
* Edit the group.
* You will see the dimmed text "General references". This is not the
CSS in this patch, but the default styling for OOUI placeholders.
* Open the dropdown. The list will show a "General references" item.
It's not dimmed. This is where the CSS was meant to be.
The CSS class name in the OOUI mixin was actually changed from
"oo-ui-flaggableElement-…" to "oo-ui-flaggedElement-…" via I1abecd8,
just a few days later.
In addition the selector wouldn't work anyway for other reasons.
The dropdown is not inside the `.ve-ui-mwReferenceGroupInputWidget`
container any more but placed outside by the OOUI window manager.
And the selector's specifity is to low, at least since Ic57b3ff.
I argue it's not worth fixing it. Nobody missed it for 10 years.
Light gray text would be illegible anyway on the light gray/light
blue backgrounds used in the dropdown menu. Let's consider it dead
code and just remove it.
The class name doesn't appear anywhere else (any more):
https://codesearch.wmcloud.org/search/?q=flaggableElement
Change-Id: Ia802303737ba35cd4b14fae924b7227472f905fd
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
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
No need to manually scan for the currently selected item. And no
need to do it twice. The feature is a little hidden (calling the
method with no parameter) but always was supported.
Bug: T356871
Change-Id: I02401284eef5687eb0825d8d9ae0df294b3b4e03
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
