Open Bug 1846742 Opened 2 years ago Updated 3 months ago

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

Categories

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

Firefox 118
Desktop
Windows 10

Tracking

(Webcompat Score:1, Webcompat Priority:P2)

ASSIGNED
Webcompat Score 1
Webcompat Priority P2

People

(Reporter: ctanase, Assigned: twisniewski)

References

(Depends on 1 open bug, )

Details

(Keywords: webcompat:contact-in-progress, webcompat:site-report, webcompat:sitepatch-applied, Whiteboard: [webcompat:sightline])

User Story

platform:windows,mac,linux
impact:feature-broken
configuration:general
affects:all
branch:release
diagnosis-team:dom
outreach-assignee:denschub
outreach-contact-date:2024-11-20
user-impact-score:450

Attachments

(4 files)

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

Reproducible on mobile as well.

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
Severity: -- → S3
Priority: P3 → P1

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.

Attached file 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?

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?

Flags: needinfo?(smaug)
Flags: needinfo?(masayuki)

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

Flags: needinfo?(smaug)

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

Depends on: 1181501
Flags: needinfo?(masayuki)
User Story: (updated)
Priority: P1 → P2

Looks like there's no easy path to fix this from our end. I think we should reach out to MS to see if they are willing to fix this.

Tom, I also wonder if an intervention could be made like we monitor the keydown/keyup and manually dispatch a click event?

Flags: needinfo?(twisniewski)
Flags: needinfo?(twisniewski)
Keywords: leave-open
Assignee: nobody → twisniewski
Status: NEW → ASSIGNED

I reached out to Microsoft on the usual channel, and also let them know about the upcoming intervention.

User Story: (updated)
Pushed by twisniewski@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/178b76601dba add a JS intervention on www.microsoft.com to simulate a click on search suggestions when enter is pressed on them; r=denschub,webcompat-reviewers
Whiteboard: [webcompat:sightline]
Webcompat Priority: --- → P3
User Story: (updated)
Webcompat Priority: P3 → P2
Webcompat Score: --- → 6
Webcompat Score: 6 → 3
Webcompat Score: 3 → 1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: