1846742 - [Top 100] Nothing happens when selecting and validating a search suggestion with the keyboard on microsoft.com

Status: NEW

(Web Compatibility :: Site Reports, defect, P1)

Description

[Calin Tanase]

Attachment: microsoft search suggestions.mp4

Environment:
Operating system: Windows 10
Firefox version: Firefox Nightly 118.0a1 (2023-08-01)

Steps to reproduce:

1. Go to https://www.microsoft.com/en-us
2. Click on the "Search button".
3. Type anything in the search field. (e.g. "surface").
4. Select a recommendation using the up/down arrows from the keyboard.
5. Press "Enter" on the keyboard.
6. Observe the behaviour.

Expected Behaviour:
Redirects to the selected article/product page.

Actual Behaviour:
Nothing happens after selecting and validating the searched item.

Notes:

1. Screen rec provided
2. Reproducible on Firefox Release as well
3. Not reproducible on Chrome
4. Issue found during WebCompat team [Top100] websites testing

Comment 1

[Raul Bucata]

Reproducible on mobile as well.

Comment 2

[Calin Tanase]

Attachment: search recommendations.png

Verified this issue and it's still reproducible on Firefox versions 122 and 124.

Environment:
Operating system: Windows 10
Browsers: Firefox Nightly 124.0a1 (2024-02-08) / Firefox Release 122 / Chrome 121.0.6167.86

Note:

• Not reproducible on Chrome
• Reproducible only with the recommendations with product image

Comment 3

[Thomas Wisniewski [:twisniewski]]

Their JS code does handle the key event, but ultimately does nothing more than hide the suggestions panel, and then rely on the enter keypress to activate the inside <a> link with its default action:

<li class="c-menu-item" role="presentation" title="Surface Laptop, Copilot+ PC" data-is-searchable="false" data-selected="true">
  <a role="option" aria-label="Surface Laptop, Copilot+ PC - Link" aria-setsize="11" aria-posinset="3" class="f-product" href="//www.microsoft.com/en-us/d/surface-laptop-copilot-pc/8tq2hq5xxkj9" aria-selected="true">
    <img class="c-image" src="//img-prod-cms-rt-microsoft-com.akamaized.net/cms/api/am/imageFileData/RW1j1Tr?ver=64d8&amp;w=272&amp;h=223&amp;o=f&amp;m=6&amp;f=jpg" role="none" alt="Surface Laptop, Copilot+ PC">
    <div><span><b>Surface</b> Laptop, Copilot+ PC</span></div>
  </a>
</li>

However, their code to hide the panel somehow prevents Firefox from doing that default action.

It seems tied to this line of code which is called by their t.prototype.selectSuggestion function:

          t.prototype.hide = function () {
            this.menu.setAttribute(t.ariaHidden, 'true'); // where t.ariaHidden is just "aria-hidden"

If I comment that line out in their script, then Firefox works fine. But I can't seem to make a reduced test-case out of this, so it's unclear to me what's happening.

The aria-hidden hides the menu because of this CSS:

.m-auto-suggest .c-menu[aria-hidden="true"], .c-auto-suggest .c-menu[aria-hidden="true"] {
  display: none;
}

If I disable that, then the enter keypresses work for me as well.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Reduced test-case

I think this is a website bug... The issue is that the focus is cleared by us rendering between the keydown and the keyup, which triggers the click.

Unless other browsers are triggering the legacy activation on keydown rather than keyup somehow?

Comment 5

[Emilio Cobos Álvarez (:emilio)]

So it seems we dispatch click from keypress. Masayuki, Olli, do you know why we can have a tick between keydown and keypress? That seems a bit unexpected?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Because they both come through IPC, in separate messages, IIRC. It is not spec'ed whether they should happen within the same task.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Right. And currently, eKeyPress has more data and a meaning which introduces a text input. Therefore, it's hard to fix so quickly.