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 .
This seems like the sort of thing that could potentially cause a *lot* of web compat issues. I wonder how Safari behaves.
I think this only happens with links because we don't focus links on click.
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).
Created attachment 451783 [details] Patch
> 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 .
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"
(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.
>>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.
(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 .
(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.
Created attachment 451875 [details] Patch
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.
(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.
Committed r289792 (247257@trunk): <https://commits.webkit.org/247257@trunk>