Page MenuHomePhabricator
Create Task
Maniphest T106273

Autocompletion on Special:Search page combined with "enter" key makes impossible to search a non existent article
Closed, ResolvedPublic
Actions

Description

Bug reported by Finnish Wikipedia.

On Special:Search when you type a query and hit enter key, you only have access to articles which exists.

  1. go to special:Search on Finnish Wikipedia
  2. type "tasavallan" and hit enter
  3. "Tasavallan presidentti", first suggestion, is loaded on the search form.

"tasavallan" red link result can be found by pressing "search" blue button or use the interface search field, but not with Special:Search. I've reproduced it on French Wikipedia with different words.

Suggestion would be to have the non existent result shown in a different appearance on the list.

Details

SubjectRepoBranchLines +/-
Make TitleInputWidget configurable, if term should be highlighted or notmediawiki/coremaster+6 -0
LookupElement: Make auto-highlighting the first term configurableoojs/uimaster+17 -5
Revert "Convert Special:Search to OOUI"mediawiki/corewmf/1.26wmf15+21 -25
Revert "Convert Special:Search to OOUI"mediawiki/coremaster+21 -25
Customize query in gerrit

Related Objects
Search...

StatusSubtypeAssignedTask
 OpenNoneT49145 Formally deprecate jQuery UI after we've stopped using jQuery UI in extensions and core
 OpenNoneT100270 Replace use of jQuery UI and MW UI with OOUI across all Wikimedia-deployed extensions and core
 OpenNoneT100161 Convert all of MediaWiki core to OOUI PHP (tracking)
 ResolvedMarkTraceurT85291 Implement OOUI "display format" in MediaWiki's HTMLForm
 ResolvedmatmarexT97871 PHP TextInputWidget has no 'required' config
 ResolvedmatmarexT91132 Forcefully preventing default event actions on FormLayout, ButtonWidget and ButtonInputWidget is problematic
 ResolvedmatmarexT85285 Disentangle VForms from HTMLForm code in core
 ResolvedmatmarexT101480 Remove 'wgUseMediaWikiUIEverywhere' and code forks, always using the off/false path
 DuplicateNoneT101476 [EPIC] Make mobile look and work as desired without wgUseMediaWikiUIEverywhere
 InvalidNoneT101471 Convert core forms that use MW UI with wgUseMediaWikiUIEverywhere false to OOUI FormSpecialPage or explicit OOUI PHP
 ResolvedJdlrobsonT107069 Convert HistoryAction.php to use OOUI and MW's new DateInputWidget
 ResolvedBUG REPORTmatmarexT220601 DateInputWidget reflow after infusion
 ResolvedmatmarexT220781 When filtering page history by date, the older/newer paging links don't work
 OpenNoneT107037 Convert all MW core special pages to OOUI
 ResolvedEsandersT113758 Convert DeleteAction.php/SpecialUndelete.php to use OOUI
 DuplicateNoneT171455 Dropdown widgets on Special:Delete only has partial OOUI styling
 ResolvedTTOT160236 Update action=purge page button
 ResolvedJayprakash12345T173997 Convert file delete to use OOUI
 ResolvedmatmarexT90336 The "Search" button in Special:Search cannot be styled from skins
 OpenNoneT106055 Improve "advanced search"
 ResolvedFlorianT100898 Convert Special:Search to OOUI
 ResolvedFlorianT106273 Autocompletion on Special:Search page combined with "enter" key makes impossible to search a non existent article

Event Timeline

Trizek-WMF created this task.Jul 19 2015, 2:32 PM
Trizek-WMF raised the priority of this task from to Needs Triage.
Trizek-WMF updated the task description. (Show Details)
Trizek-WMF subscribed.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 19 2015, 2:32 PM
Trizek-WMF updated the task description. (Show Details)Jul 19 2015, 2:35 PM
Trizek-WMF set Security to None.
Stryn subscribed.Jul 19 2015, 3:02 PM
Legoktm added a project: MediaWiki-Special-pages.Jul 19 2015, 3:17 PM
Legoktm added a subscriber: matmarex.
Legoktm subscribed.
Pxos subscribed.Jul 20 2015, 10:22 AM
matmarex added a project: OOUI.Jul 20 2015, 7:39 PM
matmarex added a subscriber: Esanders.

Hmm, we should probably look at various browsers' native autocompletion. We always highlight the first suggestion when it appears, so Enter chooses it. Maybe we should stop doing that. I wonder how it'd affect interfaces like VisualEditor's link inspector (@Esanders?).

(As a workaround, you can just press "Tab" once to focus on the "Search" button, and then press Enter to submit.)

Ricordisamoa subscribed.Jul 20 2015, 7:56 PM
In T106273#1465717, @matmarex wrote:

We always highlight the first suggestion when it appears, so Enter chooses it. Maybe we should stop doing that.

Yes.

Trizek-WMF added a comment.Jul 20 2015, 10:08 PM
In T106273#1465717, @matmarex wrote:

Hmm, we should probably look at various browsers' native autocompletion. We always highlight the first suggestion when it appears, so Enter chooses it. Maybe we should stop doing that. I wonder how it'd affect interfaces like VisualEditor's link inspector (@Esanders?).

The workflow is different on VE, because you can create a link to a non existent article. Here, you can't search a non existent page.

(As a workaround, you can just press "Tab" once to focus on the "Search" button, and then press Enter to submit.)

Reported as "not intuitive" by the Finnish.

matmarex added a comment.Jul 22 2015, 12:41 PM
In T106273#1465942, @Trizek-WMF wrote:

(As a workaround, you can just press "Tab" once to focus on the "Search" button, and then press Enter to submit.)

Reported as "not intuitive" by the Finnish.

Yes, I agree, I've only suggested this as a workaround if you need to use the keyboard.

matmarex added a comment.Jul 22 2015, 12:50 PM
In T106273#1465942, @Trizek-WMF wrote:
In T106273#1465717, @matmarex wrote:

Hmm, we should probably look at various browsers' native autocompletion. We always highlight the first suggestion when it appears, so Enter chooses it. Maybe we should stop doing that. I wonder how it'd affect interfaces like VisualEditor's link inspector (@Esanders?).

The workflow is different on VE, because you can create a link to a non existent article. Here, you can't search a non existent page.

Actually, it seems like it works exactly the same there.

Jdforrester-WMF subscribed.Jul 22 2015, 2:54 PM

The "workaround" is how it works in VE, yes.

matmarex merged a task: T106886: The autocomplete for the main search bar on Special:Search doesn't work as users expect.Jul 24 2015, 8:42 PM
matmarex added subscribers: Krenair, gerritbot, EBernhardson.
gerritbot added a comment.Jul 24 2015, 8:43 PM

Change 226902 had a related patch set uploaded (by Bartosz Dziewoński):
Revert "Convert Special:Search to OOUI"

https://gerrit.wikimedia.org/r/226902

gerritbot added a project: Patch-For-Review.Jul 24 2015, 8:43 PM
matmarex added a project: MediaWiki-Search.Jul 24 2015, 8:44 PM
Restricted Application added a project: Discovery-ARCHIVED. · View Herald TranscriptJul 24 2015, 8:44 PM
Jdforrester-WMF added a comment.Jul 24 2015, 8:44 PM

Eww, reverting the code? :-(

matmarex added a comment.Jul 24 2015, 8:47 PM

Yeah, unless you have a quick fix that doesn't make the UI even more confusing, I'll follow EBernhardson's suggestion to revert (although I personally think this is a rather low-severity issue, clearly others disagree). Looks like we'll have to change OOjs UI's LookupElement to resolve this properly, which might result in unexpected UI changes in VisualEditor and such.

Jdforrester-WMF added a comment.Jul 24 2015, 8:48 PM

Kill the 'autocomplete' setting on the input box.

matmarex added a comment.Jul 24 2015, 8:49 PM

But the page used to have autocompletion before it was changed to use OOUI, so that would be a regression.

Jdforrester-WMF added a comment.Jul 24 2015, 8:52 PM

But the page used to have autocompletion before it was changed to use OOUI, so that would be a regression.

Minor functionality regression is better than major styling regression.

matmarex added a comment.Jul 24 2015, 8:54 PM

It's not a major styling regression, the page used to use MediaWiki UI, which looks good enough (and close enough to OOjs UI) for simple widgets like this.

Jdforrester-WMF added a comment.Jul 24 2015, 8:54 PM

It's not a major styling regression, the page used to use MediaWiki UI, which looks good enough (and close enough to OOjs UI) for simple widgets like this.

Not for Monobook users.

gerritbot added a comment.Jul 24 2015, 9:00 PM

Change 226902 merged by jenkins-bot:
Revert "Convert Special:Search to OOUI"

https://gerrit.wikimedia.org/r/226902

matmarex mentioned this in rMW3c245536efcb: Revert "Convert Special:Search to OOUI".Jul 24 2015, 9:00 PM
matmarex mentioned this in T100898: Convert Special:Search to OOUI.Jul 24 2015, 9:03 PM
Ltrlg subscribed.Jul 24 2015, 9:20 PM
• Forrestbot added projects: WMF-deploy-2015-07-28_(1.26wmf16), MW-1.26-release.Jul 24 2015, 10:00 PM
matmarex mentioned this in T106946: Empty Special:Search should not become red.Jul 25 2015, 2:05 PM
matmarex added a parent task: T100898: Convert Special:Search to OOUI.
Florian subscribed.Jul 25 2015, 2:50 PM

This task seems to be resolved, or are there any other things to do?

matmarex added a comment.Jul 25 2015, 2:53 PM

Yeah, I'm keeping it open as a reminder, so that it doesn't happen again when we try T100898: Convert Special:Search to OOUI next time. It might be better to close it and open a separate task, I don't really care as long as we don't forget.

(Also, the change is not deployed yet, @EBernhardson mentioned he'll do it on Monday.)

Florian added a comment.Jul 25 2015, 3:34 PM

I'm fine with keeping it open :)

Nemo_bis triaged this task as Medium priority.Jul 25 2015, 5:07 PM
gerritbot added a comment.Jul 27 2015, 9:09 PM

Change 227348 had a related patch set uploaded (by EBernhardson):
Revert "Convert Special:Search to OOUI"

https://gerrit.wikimedia.org/r/227348

gerritbot added a comment.Jul 27 2015, 11:23 PM

Change 227348 merged by jenkins-bot:
Revert "Convert Special:Search to OOUI"

https://gerrit.wikimedia.org/r/227348

EBernhardson mentioned this in rMW5eafca2e86b1: Revert "Convert Special:Search to OOUI".Jul 27 2015, 11:24 PM
• Forrestbot added a project: WMF-deploy-2015-07-21_(1.26wmf15).Jul 28 2015, 12:00 AM
Jdforrester-WMF moved this task from Backlog to Next-up on the OOUI board.Jul 30 2015, 12:48 AM
Ironholds moved this task from Needs triage to Search on the Discovery-ARCHIVED board.Aug 4 2015, 8:17 AM
Jdforrester-WMF removed a project: Patch-For-Review.Aug 8 2015, 9:08 PM
• ksmith added a project: Essential-Work.Oct 27 2015, 3:49 PM
Legoktm removed projects: WMF-deploy-2015-07-21_(1.26wmf15), MW-1.26-release, WMF-deploy-2015-07-28_(1.26wmf16).Oct 27 2015, 11:08 PM
gerritbot added a comment.Nov 6 2015, 5:00 PM

Change 251527 had a related patch set uploaded (by Florianschmidtwelzow):
LookupElement: Make auto-highlighting the first term configurable

https://gerrit.wikimedia.org/r/251527

gerritbot added a project: Patch-For-Review.Nov 6 2015, 5:00 PM
gerritbot added a comment.Nov 6 2015, 5:18 PM

Change 251530 had a related patch set uploaded (by Florianschmidtwelzow):
Make TitleInputWidget configurable, if term should be highlighted or not

https://gerrit.wikimedia.org/r/251530

Florian added a comment.Nov 6 2015, 5:20 PM

If both changes above (^) get's merged, it's possible to specify a highlight option for TitleInputWidget, which will (depending on it's boolean state) allow a direct form submission with return (even if there are suggestions) or not :)

gerritbot added a comment.Nov 10 2015, 8:46 PM

Change 251527 merged by jenkins-bot:
LookupElement: Make auto-highlighting the first term configurable

https://gerrit.wikimedia.org/r/251527

matmarex closed this task as Resolved.Nov 11 2015, 5:03 PM
matmarex assigned this task to Florian.
matmarex removed a project: Patch-For-Review.

Special:Search is still not using OOUI styles at the moment, but when it does (see T100898), this issue will be gone.

gerritbot added a comment.Nov 11 2015, 5:11 PM

Change 251530 merged by jenkins-bot:
Make TitleInputWidget configurable, if term should be highlighted or not

https://gerrit.wikimedia.org/r/251530

ReleaseTaggerBot added projects: MW-1.27-release (WMF-deploy-2015-11-17_(1.27.0-wmf.7)), MW-1.27-release-notes.Nov 11 2015, 6:00 PM
Jdforrester-WMF moved this task from Next-up to Reviewing on the OOUI board.Nov 21 2015, 2:29 AM
Pxos unsubscribed.Dec 17 2015, 11:44 PM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits