Bug 236217

Summary: REGRESSION(r195447): [GTK] document.activeElement not set on mouse click
Product: WebKit Reporter: Дилян Палаузов <dpa-webkit>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: bugs-noreply, cdumez, cgarcia, changseok, esprehn+autocc, ews-watchlist, gyuyoung.kim, mcatanzaro
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
ews-feeder: commit-queue-
Patch mcatanzaro: review+

Дилян Палаузов
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 &lt;body&gt;&lt;/body&gt;, instead of the &lt;a&gt; element. In all other browsers, or when the element is focused with the keyboard/TAB, console will print the &lt;a&gt; 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-
DetailsFormatted DiffDiff
Patch (5.44 KB, patch)
2022-02-14 02:20 PST, Carlos Garcia Campos 		mcatanzaro: review+
DetailsFormatted DiffDiff
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.