Page MenuHomePhabricator

[Regression wmf.1] Search is not returning matched article names in the link target suggestion drop down inside link inspector
Closed, ResolvedPublic1 Story Points

Description

  1. Open link inspector
  2. Type "Link"

It briefly brings up the results that starts with the word link and then reloads some unmatched article suggestions

Details

Related Gerrit Patches:

Event Timeline

Ryasmeen created this task.Sep 29 2015, 8:53 PM
Ryasmeen raised the priority of this task from to High.
Ryasmeen updated the task description. (Show Details)
Ryasmeen added a project: VisualEditor.
Ryasmeen added a subscriber: Ryasmeen.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 29 2015, 8:53 PM
Ryasmeen added a comment.EditedSep 29 2015, 8:56 PM

It could be due to the slowness in the overall search mechanism, I feel it has got significantly slower after this change: https://phabricator.wikimedia.org/T101169

Perhaps the request for suggestions beginning with "L" was not canceled, and arrived after the suggestions for "Link"? The network panel in the browser inspector should show you what's happening, and also how slow these requests are.

This appears to happen because TitleWidget doesn't abort pending requests, and requests are able to overtake each other. A similar bug probably caused T114178: [Regression wmf.1] Search results appear in the drop down even after clearing the search term inside the link inspector. Additionally, results aren't cached, so if you type "Head", then press backspace, then type "d" again, you'll see a repeated request for "Head" (and also for "Hea").

Why wasn't LookupElement reused here? :S We solved all these problems years ago, over the course of multiple painful months.

Jdforrester-WMF renamed this task from [Regression pre-wmf1]Search is not returning matched article names in the link target suggestion drop down inside link inspector to [Regression wmf.1] Search is not returning matched article names in the link target suggestion drop down inside link inspector.Sep 29 2015, 9:18 PM
Jdforrester-WMF assigned this task to Esanders.
Jdforrester-WMF set Security to None.
Jdforrester-WMF edited a custom field.

The main difference was the appearance. LookupElement renders as an absolutely position overlay, whereas SearchWidget is visually what we are aiming for. I'm not happy that we have such similar widgets (Input+Lookup vs Search) with such different APIs...

DLynch claimed this task.Nov 11 2015, 10:19 PM
DLynch added subscribers: Esanders, DLynch.

Since this is the same cause as T114178, my fix for that will have fixed it.

Once https://gerrit.wikimedia.org/r/#/c/252388/ is approved, I'll rewrite TitleSearchWidget to use the new RequestManager mixin it provides, and then it'll pick up the same caching benefits that LookupWidget brings.

Change 252592 had a related patch set uploaded (by DLynch):
[WIP] TitleSearchWidget: Use OO.ui.mixin.RequestManager

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

My OOUI patch landed. After the next OOUI release (Tuesday) I'll get the rewrite of TitleSearchWidget landed.

Jdforrester-WMF closed this task as Resolved.Nov 19 2015, 9:14 PM
Jdforrester-WMF removed a project: Patch-For-Review.

Change 252592 merged by jenkins-bot:
TitleSearchWidget: Use OO.ui.mixin.RequestManager

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