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
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
This makes the dialog's behavior much more robust, especially when
confronted with overly long and complex references.
* Limit the height of list items to avoid the situation where a
single item overflows the dialog. This makes it especially hard
to navigate with the cursor keys. We can't see any more what's
going on. The proposed height is intentionally a very high upper
bound, equivalent to about 2/3 of the dialog's height.
* Limit the name on the right side to take up less than half of an
item. The left side is for the content. Usually the names are very
short anyway. But if a name is long it currently creates a mess
where the name is intertwined with the content.
* Break overly long words in references.
* Changing the opacity to use upstream values makes the dimmed names
a bit darker. I think this is good, even necessary for legibility.
Technical changes:
* Use LESS variables from upstream, where possible.
* Remove redundant `relative` already set upstream.
Bug: T372385
Change-Id: Ie59b7b7e4aa7eadc8f82b39884313f5aa8cfd950
This is really just a bug. The reuse tab in the reference dialog
always supported keyboard actions (cursor up and down). It was just
impossible to see it because the OOUI base widget we use here doesn't
come with a default styling for this. I suspect this got lost with
some OOUI update years ago. Let's just fix it.
The colors are what OOUI dictates for this situation.
Bug: T360034
Change-Id: I6cfd423830bc0cc86b1aff5dc08a53c49b6e2d9f
Note this actually changes the "subtle" color to be darker. As far
as I understand this is an intentional decision. The old color token
from OOUI is deprecated and intentionally made darker in Codex.
See Ie667c35 and most notably T313502.
Change-Id: I37ad25aa6821d61fe3321e1390d1ccf987075250
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
