Closed Bug 1794478 Opened 3 years ago Closed 6 months ago

Fragment identifer #top does not move focus to top.

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Version:
Firefox 105
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: estelle, Unassigned)

Details

(Whiteboard: domcore-bugbash-triaged)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:105.0) Gecko/20100101 Firefox/105.0

Steps to reproduce:

I created a link at the bottom of the page:

<a href="#">Go to top</a>

and

<a href="#top">Go to top</a>

and clicked on the link, and then hit the tab key..

Actual results:

The page scrolled to the page, as it should when I clicked the link.
When I clicked the tab key focus was returned to the next link at the bottom of the page.

Expected results:

When a link with a fragment identifier is clicked, the section scrolls into view. This part works, as per the specification, https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-the-fragment-identifier, the 8 bullet point list #2 and #7.

activating a link and scrolling on any other fragment identifier target into content, keyboard tab index enters into that section of content. With # and #ToP (case-insensitive), focus/keyboard order stays with the link.

This makes both these default features not usable because of accessibility and generally bad user experience.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: UI Events & Focus Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: UI Events & Focus Handling
Product: Firefox → Core

The severity field is not set for this bug.
:sefeng, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sefeng)

Hi, it's not clear to me which part of the spec we violate, could you please be more specific? As far as I can tell, chrome also behaves the same.

Thanks!

Severity: -- → S3
Flags: needinfo?(sefeng) → needinfo?(estelle)

I filed a WHATWG HTML bug: https://github.com/whatwg/html/issues/8439

We behave as expected, aligned with the current specification. Once the spec issue is resolved, we can have a new bug for the agreed change, if any.

Status: UNCONFIRMED → RESOLVED
Closed: 6 months ago
Flags: needinfo?(estelle)
Resolution: --- → INVALID
Whiteboard: domcore-bugbash-triaged
You need to log in before you can comment on or make changes to this bug.