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 Thank you. I agree that it should not be a blocker for deployment

@ovasileva did you mean to decline this or move to tracking? If tracking, can I suggest we do decline this as moving to tracking as this is likely going to mean this never gets resolved.

In T273513#7182564, @Jdlrobson wrote:

@ovasileva did you mean to decline this or move to tracking? If tracking, can I suggest we do decline this as moving to tracking as this is likely going to mean this never gets resolved.

Triaged but future is okay here. I was intending to only keep it on the desktop refresh board as something we could potentially consider later on in the project.