Page MenuHomePhabricator

Investigate adding a "fake" search button
Open, MediumPublic5 Estimated Story Points

Description

Description

Currently we have a "fake" search UI which gets replaced by the "real" (ie WVUI) search UI once someone interacts with it. However the search button is not part of the fake search UI. This creates two minor issues:

  1. the search button is meant to appear on hover, which currently does not happen unless the search field has already been interacted with (and thus the WVUI version has loaded). To better understand compare these two GIFs of a person hovering their mouse over the search field:
before WVUI has loadedafter VWUI has loaded
  1. the second issue here is that on a slow connection the search button can take over a second to appear, and therefore might distract someone from typing their search term and/or scanning the results list:

Event Timeline

Currently we have a "fake" search UI which gets replaced by the "real" (ie WVUI) search UI

FWIW it's not fake. This is what will serve our non-JavaScript users ;)

However the search button is not part of the fake search UI. This creates two minor issues:

Actually, there is a button already in the HTML DOM that could be used to provide this display on hover effect (so no need for a "fake" one ;-)). Right now this button with ID #mw-searchButton is hidden under the search icon. This could be pulled out to appear on the right of the input.

Note this is going to be tricky - this would require some adjustments around the width of the input. Right now the text input takes up width 100% and we'd need to make space for the button on hover. This will definitely add complexity to the component.

@nray any thoughts on this prior to estimation? I think you may also have some insights.

Sorry for the delay on this. I'm planning on looking into this more today

Change 665409 had a related patch set uploaded (by Nray; owner: Nray):
[mediawiki/skins/Vector@master] POC: Server render a search button that looks like WVUI search button

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

Change 665409 abandoned by Nray:
[mediawiki/skins/Vector@master] POC: Server render a search button that looks like WVUI search button

Reason:
POC only

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

Okay, I've looked into this more and made a POC. The POC was worthwhile as it exposed several gotchas that make this ticket not so trivial:

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

First, the good news - using the mediawiki.ui mixins to add the button styles works pretty well with minimal extra styles needed to make the search button look like the WVUI search button.

Now the gotchas:

  • We are not only needing to render a search button that looks like the WVUI search button, but we also need the styles that make it look like the button is "encapsulated" by the input box when the user hovers. SSR the WVUI input and including those relevant style would really be helpful here, but we are unfortunately not there yet.
  • There are issues with search button opacity transition/input border transition firing when the page loads. It is likely caused from the infamous chrome rendering bug [1][2]. Use of the`.vector-animations-ready` class like we do for the sidebar [3] is likely needed here to prevent this.
  • I notice a flicker of the search button when WVUI replaces the server rendered search button. The WVUI button is transitioning from 0 opacity to 1 opacity which is what causes this. One way to address this would be to add a class that would only permit transitions after the WVUI components have mounted and rendered, however it adds some complexity.
  • The use of #searchButton to display the magnifying glass is problematic because this button needs to be place before #mw-searchButton in the DOM to accomplish the goals of this ticket. However, as a result, go will be sent as a query param instead of the fulltext query param provided by #mw-searchButton when users submit the search form with the enter key prior to loading WVUI. I think having a span render the magnifying glass instead of #searchButton would be less hacky here.

[1] https://lab.laukstein.com/bug/input
[2] https://github.com/nicholasray/chrome-heisenbug
[3] https://github.com/wikimedia/Vector/blob/159ad59806e2ad23d3d4e04ede4bc4c5449e5579/resources/skins.vector.styles/Sidebar.less#L76

ovasileva triaged this task as Medium priority.Feb 22 2021, 12:03 PM

Thanks @nray! Tagging this as next-up, but medium priority. Not considering it a blocker for deployment.

@ovasileva Thank you. I agree that it should not be a blocker for deployment

ovasileva set the point value for this task to 5.Feb 24 2021, 5:30 PM