Thanks for the report! Is there anything you can share about how this was being used in your site to help us prioritize?

Hi!

When I encountered this bug I was basically trying to make an ordered list of links, displayed left to right, each link having a box above the link text showing a counter. Kind of like

 1     2     3
Foo > Bar > Baz

There seem to be some workarounds for my case. I replaced the generated content with regular HTML elements to avoid the bug, but also ended up absolutely positioning the numbers so that only the visible parts would be clickable (they have background and border-radius). This (or other ways of taking the :before out of the normal flow, at least float; or making the link into an inline-block) seems to avoid the bug too.

Since this involves clicking on a link, let's get it onto the input-dev triage queue.

The hit test is returning the fact that the node is not the anchor but the parent paragraph. The click is then targeted to the paragraph

If the display style is inline or the anchor's display is block then it is interpreted correctly. I presume there is a bug with the hit testing for inline block elements. 

I think this may be a regression.

This is a regression from: https://src.chromium.org/viewvc/blink?revision=193975&view=revision

+dsinclair

dsinclair does not work on Chromium any more.

I don't work on blink, but I do work on chromium.

Right, sorry.

If I may, I'd like to report the same issue for Comodo Dragon (57.0.2987.93 on Windows 7 32-bit). 

As a test case there's the site I'm a co-editor of. On this page, http://palaeos.com/vertebrates/theropoda/index.html , for instance, the top navigation bar items labelled "Page Next:", "Page Back:", "Unit Next:", etc. and similarly on the bottom navigation bar along with "Top of page" don't react as links to hovering and don't work as links. All of these are generated text, pseudo-elements with "display: block" attached to a <span> within an anchor. "Taxon Index" is set up similarly but as "display" is set to "inline" it works as it should. 
On this other page, http://palaeos.com/vertebrates/index.html , for some of the aforementioned items there is text outside the <span> but within the anchor. Hovering that normal text has both it and the generated text react to hovering.

This works on SeaMonkey (2.46) and Internet Explorer (11.0.9600.18665) and it worked on Google Chrome (3 years ago IIRC) for at least as long as it took me to test the webpages' rendering  (all on the same computer). I'd frankly like to not have to slog it through 1600+ files to either revert this or implement a workaround.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Still happens. I thought maybe I had fixed it, but apparently not.

 Issue 884131  has been merged into this issue.

https://chromium-review.googlesource.com/c/chromium/src/+/1226616

 Issue 884131  was just duped into this. That originated from https://github.com/webcompat/web-bugs/issues/17453. As with this issue, Chrome was the outlier and Edge, Firefox and Safari agreed on another behavior. So Hotlist-Interop is appropriate.

Since this has been independently stumbled upon by at least two people and is a case where Chrome alone could fix the interop issue, may I ask about the effort to fix this?

Oops, I did not see #21 before posting. That was fast :)

 Issue 92917  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bbbce17933cfd44f7ef36d54d9a7d3746aa68c3c

commit bbbce17933cfd44f7ef36d54d9a7d3746aa68c3c
Author: Rune Lillesveen <futhark@chromium.org>
Date: Mon Sep 17 09:50:50 2018

Correct inner node for hit-testing of pseudo elements.

We incorrectly walked the layout tree for ::before/::after element
ancestors instead of just looking up the originating element. We still
need to traverse anonymous inclusive ancestors of the ::first-letter
text, though.

Bug:  884131 ,  644093 ,  92917 
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ie010535caea76f8c2676482aa38ece8dbcf6d3fb
Reviewed-on: https://chromium-review.googlesource.com/1226616
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591628}
[modify] https://crrev.com/bbbce17933cfd44f7ef36d54d9a7d3746aa68c3c/third_party/blink/renderer/core/dom/first_letter_pseudo_element.cc
[modify] https://crrev.com/bbbce17933cfd44f7ef36d54d9a7d3746aa68c3c/third_party/blink/renderer/core/dom/first_letter_pseudo_element.h
[modify] https://crrev.com/bbbce17933cfd44f7ef36d54d9a7d3746aa68c3c/third_party/blink/renderer/core/dom/pseudo_element.cc
[modify] https://crrev.com/bbbce17933cfd44f7ef36d54d9a7d3746aa68c3c/third_party/blink/renderer/core/dom/pseudo_element.h
[modify] https://crrev.com/bbbce17933cfd44f7ef36d54d9a7d3746aa68c3c/third_party/blink/renderer/core/layout/hit_test_result.cc
[modify] https://crrev.com/bbbce17933cfd44f7ef36d54d9a7d3746aa68c3c/third_party/blink/renderer/core/paint/paint_layer_test.cc

There is still something a bit odd going on here, with a difference now between Edge and the other engines in whether hover next to the span counts changes the color:
https://github.com/webcompat/web-bugs/issues/17453#issuecomment-422361442