236217 – REGRESSION(r195447): [GTK] document.activeElement not set on mouse click

RESOLVED FIXED 236217

REGRESSION(r195447): [GTK] document.activeElement not set on mouse click

https://bugs.webkit.org/show_bug.cgi?id=236217

Summary REGRESSION(r195447): [GTK] document.activeElement not set on mouse click

Дилян Палаузов

Reported 2022-02-06 22:46:17 PST

In Firefox 96 and Chromium 96, when I call document.activeElement within a mouse-click handler, it points to the element, which got clicked. In Epiphany 41.3/WebGitGTK 2.34.4 and MiniBrowser/WebKitGTK 2.34.4 document.activeElement points to the <body> element in the mouse-click handler. In all browsers, when I use TAB to select an element and then press enter, document.activeElement points to that element. Sample: ``` <!DOCTYPE html> <html> <style> a:focus-visible, a:focus { outline: dashed 4px } </style> <body> <a href='#' onclick='console.log(document.activeElement)'>If this is clicked with the mouse, once the document is loaded, in Epiphany the console will emit <body></body>, instead of the <a> element. In all other browsers, or when the element is focused with the keyboard/TAB, console will print the <a> element.</a> <p>See also <a href='https://gitlab.gnome.org/GNOME/epiphany/-/issues/1695'> https://gitlab.gnome.org/GNOME/epiphany/-/issues/1695</a></p>. </body></hmtl> ``` See also https://gitlab.gnome.org/GNOME/epiphany/-/issues/1695 .

Attachments
Patch (4.46 KB, patch) 2022-02-12 05:34 PST, Carlos Garcia Campos	ews-feeder: commit-queue-	Details Formatted Diff Diff
Patch (5.44 KB, patch) 2022-02-14 02:20 PST, Carlos Garcia Campos	mcatanzaro: review+	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Michael Catanzaro

Comment 1 2022-02-07 06:25:18 PST

This seems like the sort of thing that could potentially cause a *lot* of web compat issues. I wonder how Safari behaves.

Carlos Garcia Campos

Comment 2 2022-02-11 06:08:53 PST

I think this only happens with links because we don't focus links on click.

Carlos Garcia Campos

Comment 3 2022-02-12 03:00:32 PST

This behavior is desired for apple ports, but for GTK it regressed in r195447. I've checked chromium and firefox and they both set the focus on links when clicking, so I think we can restore the behavior for GTK (and WPE).

Carlos Garcia Campos

Comment 4 2022-02-12 05:34:27 PST

Created attachment 451783 [details] Patch

Дилян Палаузов

Comment 5 2022-02-12 05:47:24 PST

> This behavior is desired for apple ports, Does this mean, that on purpose document.activeElement in Safari with mouse-click works in a different way, compared to other browsers? May I ask what is the background for this deviation? I wanted to write code using document.activeElement. Eventually I achieved the same functionality without using document.activeElement. This distinction, made on purpose, shall be documented with the rationale behind it, e.g. at https://github.com/mdn/browser-compat-data/issues/14866 .

Michael Catanzaro

Comment 6 2022-02-12 07:22:53 PST

Comment on attachment 451783 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=451783&action=review Need to look at: imported/blink/fast/events/click-focus-keydown-no-ring.html > LayoutTests/fast/events/click-focus-anchor.html:7 > <p>This test ensures that we can click to focus an a element. Please fix preexisting typo: "focus an element"

Michael Catanzaro

Comment 7 2022-02-12 07:24:13 PST

(In reply to Дилян Палаузов from comment #5) > May I ask what is the background for this deviation? That's probably just how links behave on macOS? It's normal for UI elements to behave differently on macOS vs. Windows. WebKitGTK generally aims to match Safari with respect to web platform behavior, but in regards to UI concerns like "what happens on mouse click," we tend to more often match Windows or GTK behavior.

Дилян Палаузов

Comment 8 2022-02-12 09:28:47 PST

>>This test ensures that we can click to focus an a element. > Please fix preexisting typo: "focus an element" I thought initially also, that this is a typo. But the a means anchor. So the above says: This test ensures that we can click to focus an anchor element.

Carlos Garcia Campos

Comment 9 2022-02-14 00:39:36 PST

(In reply to Дилян Палаузов from comment #5) > > This behavior is desired for apple ports, > Does this mean, that on purpose document.activeElement in Safari with > mouse-click works in a different way, compared to other browsers? > > May I ask what is the background for this deviation? See bug #18425 > I wanted to write code using document.activeElement. Eventually I achieved > the same functionality without using document.activeElement. This > distinction, made on purpose, shall be documented with the rationale behind > it, e.g. at https://github.com/mdn/browser-compat-data/issues/14866 .

Carlos Garcia Campos

Comment 10 2022-02-14 02:00:43 PST

(In reply to Michael Catanzaro from comment #6) > Comment on attachment 451783 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=451783&action=review > > Need to look at: imported/blink/fast/events/click-focus-keydown-no-ring.html I think this is chromium specific behavior, at least it's not consistent with firefox. I don't see why not drawing the focus ring when pressing a key while a link is focused. > > LayoutTests/fast/events/click-focus-anchor.html:7 > > <p>This test ensures that we can click to focus an a element. > > Please fix preexisting typo: "focus an element" Confusing but not a typo.

Carlos Garcia Campos

Comment 11 2022-02-14 02:20:42 PST

Created attachment 451875 [details] Patch

Michael Catanzaro

Comment 12 2022-02-14 06:50:31 PST

Comment on attachment 451875 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=451875&action=review > Source/WebCore/html/HTMLAnchorElement.cpp:105 > +#if !(PLATFORM(GTK) || PLATFORM(WPE)) I would guard this with #if PLATFORM(COCOA) instead, since I suspect other non-Apple ports want our behavior.

Carlos Garcia Campos

Comment 13 2022-02-15 00:32:53 PST

(In reply to Michael Catanzaro from comment #12) > Comment on attachment 451875 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=451875&action=review > > > Source/WebCore/html/HTMLAnchorElement.cpp:105 > > +#if !(PLATFORM(GTK) || PLATFORM(WPE)) > > I would guard this with #if PLATFORM(COCOA) instead, since I suspect other > non-Apple ports want our behavior. I prefer not to change the behavior of other ports, this was always specific to GTK, EFL and Qt, but not win.

Carlos Garcia Campos

Comment 14 2022-02-15 00:34:35 PST

Committed r289792 (247257@trunk): <https://commits.webkit.org/247257@trunk>

Note You need to log in before you can comment on or make changes to this bug.

Status RESOLVED

Resolution FIXED

Priority P2

Severity Normal

Classification Unclassified

Version WebKit Nightly Build

Hardware Unspecified

OS Unspecified

Product WebKit

Component WebKitGTK

Assignee

Nobody

Reported

2022-02-06 22:46 PST

Modified

2022-02-15 00:34 PST History

CC List

8 users Show

URL

Keywords

Depends on

Blocks