In T229832#5414240, @DLynch wrote:Following up on my earlier suggestion to document things...
We could switch these to an OOJS-UI SearchInputWidget, probably. Easier for external than internal, because internal uses mw.widgets.TitleSearchWidget and we might need to make sure there wouldn't be any side-effects there.
I got a patch merged to OOUI that makes SearchWidget use a SearchInputWidget rather than a TextInputWidget. Mediawiki core's TitleSearchWidget extends SearchWidget, so that means that when the chain of dependency updates finishes going through, our internal-link search is going to have the ⓧ in its input.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T221247 [Epic] Mobile context items | |||
| Open | None | T231847 Add ⓧ buttons in the form input fields to make text deletion easier |
Event Timeline
Comment Actions
Still to be decided:
- What fields should receive the "ⓧ"? Search inputs? All text input fields?
- What are the patterns/rules that define what fields should receive the "ⓧ"?
Comment Actions
From the patch where we started discussing this:
My initial thought was that anything with autocomplete ("search", in practice) should definitely have it, just because it's going to be fairly easy to accidentally drop a long string in and then want to change the entire thing.
As a guiding principle, I'd think any field where a _likely_ change is "I want to replace this entire thing". For URLs like this, it seems very plausible that the most common editing pattern is really going to be clearing it and then pasting the new version in, even if it's technically a small 1 character change somewhere in the URL.
If we're looking for platform consistency, the X is a feature that's given out to <input type="search">.
Comment Actions
New design work of this nature for Visual Editor isn't being prioritized at this moment.
Comment Actions
This is a question which is lightly holding up this ticket in code review: https://phabricator.wikimedia.org/T229839
Comment Actions
Removing task assignee due to inactivity, as this open task has been assigned for more than two years. See the email sent to the task assignee on February 06th 2022 (and T295729).
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome.
If this task has been resolved in the meantime, or should not be worked on ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator.