We discovered that the label can be really long depending on the
language. On mobile, where the screen is quite narrow it seems
more useful to let it wrap.
In this context it's even more relevant, because the options you
can choose from might only differ in the last parts of the message.
Bug: T375053
Change-Id: I9ec111ab1b80843f993d605ff11a1702c3d7b37c
We want the tooltip on the entire search result item, but not on
the button. The button probably needs a dedicated tooltip. To be
discussed. Let's start with removing the wrong tooltip.
Bug: T375053
Change-Id: I69da1f3cf80cf94342498a30b47acac8412d08ca
Adding a submenu to the results of the reference re-use search.
This allows the user to either create a direct reuse or a reuse with
different details.
Hide the menu when there's a sub-reference.
Known Issues:
- Ref name is hidden (conditionally when our feature is enabled) as a
quick fix to not having a good layout choice yet.
- Submenu is clipped at the dialog bounds.
- Submenu highlight should vanish when the submenu is closed
- Instrument action with metrics.
Bug: T375053
Change-Id: I3eddd6bad328aaf9bb99eb2783ba66d4e08f862d
Hide some knowledge from the reference dialog, and prepare the way
for additional events such as "extends".
Bug: T375053
Change-Id: I6097eb85deadcb58d1f56844c65726f19dbf6dda
The exact rendering of each item should be part of the widget.
This also allows a better application of the sub-ref indent.
Bug: T375841
Change-Id: Ic2c24f40d59f41b316c6d6f362726c1ee68f2102
TODO: This can be merged as-is, since it only affects pages with
subrefs, but it behaves surprisingly when the ref body is long. In
this case, the text wraps around and flows onto the next lines
unindented.
A full implementation would require deeper changes to the item pane
layout, which is happening in a separate patch. Recommend merging
this as a quick visual fix and then we come back to the subref+long
content edge case once the pane is easier to adjust layout in.
Bug: T375841
Change-Id: I65510f1550e033e57a3493676d8fc24f628c0600
Pushes per-group knowledge down into a structured object and give it
an interface, separated from the singleton cache across all groups.
Also changes the behavior of orphaned subrefs so that they're still
rendered as subrefs, with an error placeholder where the parent
should be.
Bug: T372871
Change-Id: I84e679a8365f3fbfabaf344d99f56f6d069c0776
This patch gives us the same number as will appear in the document,
even when subrefs are present.
Tests could be improved using sinon to check some call assertions
but should be fine for now.
Removed the test for placeholders, because these should be filtered
in MWDocumentReferences.getGroupRefsByParents()
Bug: T370874
Change-Id: I7543a6593308c529bcfbeb0835a7c0882cbf8621
The internal search index is optimized and expects everything to be
lowercase. This was already done for the text, but not for the name
and group. As far as I can see in the Git history this problem always
existed ever since this code was written.
This fixes an 11 (!) year old bug.
Bug: T53838
Change-Id: I12b3b7c23d34d49b630e9151525409dbddfac24e
Note that the duplicated search panel is most probably a temporary
solution anyway. We probably want a single search panel that can do
both kinds of "reuse with/without different details".
This is also inconsequential for production. Nothing related to
extended references is currently visible on production.
Added to the otherwise unrelated T369005 for code review purposes.
Bug: T369005
Change-Id: Iedee38dacc01ae59fb1a681e49e655ca91b25b64
Mainly to support the activity tracking use case where we want to
track an active use everytime the user starts anew in this UI.
Bug: T368533
Change-Id: Iecf7e697bbbd637c4a00a44debf615c2351eb390
C&P mistake in the original implementation. Otherwise we end up
with an undefined in the name.
Bug: T362347
Change-Id: I5c6957ca9fc81e6a5211aab050025eea5d0addbe
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
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
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
It's fine to copy attributes directly from the reference node rather
than go through the specialized model object.
Bug: T336417
Change-Id: Idaca192137dc762ddced2ee8446a7d838f97e317
I assume the code was using lastIndexOf as some kind of performance
optimization. Certain StackOverflow threads suggest it without going
into detail. It's not correct here. You can actually name a group
"mwReference/", which will result in the (valid) internal name
"mwReference/mwReference/". This works as expected with indexOf but
not with lastIndexOf.
Change-Id: I8e85ae5c11a74016c7720fcdb6ac6478431aaa8e
This fixes a minor inconsistency: A reference that comes from a
template and is already reused outside of the template is only
partially available to VE, and previewed with a warning message
because of this:
"This reference is defined in a template or other generated block,
and for now can only be previewed in source mode."
This was missing in the reuse dialog.
Note this patch is not meant to make any design decision, but to use
the existing design consistently.
You can test this with and without the Citoid extension. It works in
both cases.
Bug: T336372
Change-Id: I962cf111b1882bcd736f1090ca17d2b176495d2f
This is a prerequisite before any work related to T52568 (being able
to manually name references in VisualEditor) can start.
Why these names should not be hidden:
* We don't know if the name is actually part of the auto-generated
sequence in the current article or copy-pasted from somewhere else.
* Manually given names that start with a colon are currently hidden
even if they are unrelated to the auto-generated sequence.
* The information is highly relevant for users switching between VE
and wikitext. Especially when a reference is used multiple times
the relevant wikitext can be as short as <ref name=":0" />. The
literally only information in this case is the number.
Since these numbers are still more technical than anything we make
them very dim to emphasize the contrast to non-numeric names.
Bug: T52568
Bug: T92432
Change-Id: I65cb6998cb5f8659cd9043f3d4aaeac1c5f69da8
Generating the preview from the model is much slower and not
required in this context.
Bug: T310318
Change-Id: I73ab222c268939eb542aaae8b529446eae45abc7
