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
This reverts commit 0566a495f3.
Reason for revert: Merged too soon, while discussion of the whole
approach is still ongoing.
Change-Id: I2d3d6455cd4ea12067e2020f6b41cfbb4672bbb5
It's fine to copy attributes directly from the reference node rather
than go through the specialized model object.
Bug: T336417
Change-Id: Idaca192137dc762ddced2ee8446a7d838f97e317
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
In articles with references, a reference list is generated. If you
try to visual edit the reference list, it displays a message "This
reference list is generated by a template, and for now can only be
edited in source mode." However it is actually editable now that
T54750 (Community Wishlist 2023 wish #2) is complete.
Bug: T54750
Change-Id: Id8115ae6045f371e4619c85aeb610fe78927d802
* Be more specific about the type of context which a
context item belongs to.
* Make grammar clearer.
Change-Id: I9bcc129766c3386582def0f346d6f175e54d6ff6
This reverts commit da30b2b626.
Reason for revert: Caused a regression. Feature is not enabled on public wikis so reverting is harmless for now.
Bug: T247922
Bug: T340757
Change-Id: I83434afaf1b76425bddb575dd724f462a247c83d
