Bug 312692
| Summary: | Add site-specific quirk to make anchor elements mouse-focusable on thesaurus.com | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Sean Patterson <sean_patterson> |
| Component: | UI Events | Assignee: | Abrar Rahman Protyasha <a_protyasha> |
| Status: | NEW | ||
| Severity: | Normal | CC: | alexander, karlcow, webkit-bug-importer, webkit |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 26 | ||
| Hardware: | Mac (Apple Silicon) | ||
| OS: | Unspecified | ||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=229895 https://bugs.webkit.org/show_bug.cgi?id=22261 https://bugs.webkit.org/show_bug.cgi?id=18425 https://bugs.webkit.org/show_bug.cgi?id=267449 |
||
Sean Patterson
rdar://174959285
WebKit ignores preventDefault() on mousedown events when determining whether to change focus. The HTML spec defines mousedown's default action as including the "focusing steps", so calling preventDefault() should cancel the focus change.
This is the standard pattern used by virtually every custom autocomplete/dropdown component: calling preventDefault() on mousedown to prevent the input from losing focus (and hiding the dropdown) when clicking a suggestion item. Sites like thesaurus.com rely on this.
Steps to reproduce:
1. Go to https://www.thesaurus.com/
2. Type a word in the search box
3. Click a suggestion in the autocomplete dropdown
Expected: The suggestion is selected and navigates to the result page.
Actual: Nothing happens. The dropdown disappears because the input loses focus (blur fires), removing the suggestion elements from the DOM before the click event reaches them.
Root cause:
In EventHandler::dispatchMouseEvent(), after dispatching the mousedown event, the eventIsDefaultPrevented flag is captured but only used for m_capturesDragging. The focus-change code (lines 3349-3410) runs unconditionally, never checking whether the default was prevented.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Sean Patterson
That's initial root cause isn't accurate. It's not preventDefault(). The real root cause: HTMLAnchorElement::isMouseFocusable() returns false for <a href> links without explicit tabindex on non-GTK platforms.
This is a deliberate Safari behavior (links don't gain focus on click). But it means:
- Blur's relatedTarget is null when clicking a link
- Sites relying on relatedTarget in blur handlers (like thesaurus.com) break
- Chromium focuses links on click, so relatedTarget is populated and these sites work
Sean Patterson
Pull request: https://github.com/WebKit/WebKit/pull/63082
Karl Dubost
Just to note that this is a regular discussion inside the WebKit team.
And there is a lot of history around it.
Karl Dubost
I don't know if we will be able to collectively the larger discussion in a reasonable time, but if we want to fix it for thesaurus, we could create a Quirk that would solve it in the meantime for Thesaurus.
Would that be an acceptable compromise.
Karl Dubost
* collectively resolve the larger discussion
Alex
The stubbornness of the webkit team on the subject is unbelievable. The whole wide world works this way, over 80% of global internet population interacts with the web in a way that does focus buttons and links on click and they are absolutely fine. But Apple has to know better than the rest, they are special. And us, the webdevs, suffer jumping through hoops for literally DECADES (how's that for "reasonable time"?) to get the web to behave reliably.
Karl Dubost
Alex, This is an *active* discussion these days.
The WebKit team is trying to find the best path that will make it possible to
1. Be compatible with the Web
2. Not break the apps that are using the WebKit engine and expect the current behavior
3. Not create Web Compatibility issues for users going to websites with specific codepaths for Safari.
4. Make sure, it fits well with the current accessibility tools on macOS/iOS.
It's tricky. :/
We definitely hear the web developer community and the pain it creates.
It also leads to have to create Quirks which is far to be ideal too.
https://searchfox.org/wubkat/rev/bfd8c838d8a13454ce270c5429cd57549ffc98fe/Source/WebCore/page/Quirks.cpp#250-262
```cpp
// ceac.state.gov https://bugs.webkit.org/show_bug.cgi?id=193478
// weather.com rdar://139689157
// madisoncity.k12.al.us https://bugs.webkit.org/show_bug.cgi?id=296989
bool Quirks::needsFormControlToBeMouseFocusable() const
{
#if PLATFORM(MAC)
QUIRKS_EARLY_RETURN_IF_DISABLED_WITH_VALUE(false);
return m_quirksData.quirkIsEnabled(QuirksData::SiteSpecificQuirk::NeedsFormControlToBeMouseFocusableQuirk);
#else
return false;
#endif // PLATFORM(MAC)
}
```
Alex
Nothing will break if you just enable focus on click for buttons, checkboxes, links and everything else and not show focus ring, like LITERALLY every other browser. I'm genuinely appalled you guys just add giant if else with hardcoded websites that get a privilege of working properly, absolutely amazing.
Sean Patterson
I reverted the original fix and made it a quirk for now.