Hoverable comments link from linkedin have no space between word and line
Categories
(Web Compatibility :: Site Reports, defect, P3)
Tracking
(firefox-esr78 affected, firefox68 affected, firefox69 affected, firefox70 affected, firefox71 affected, firefox72 affected, firefox73 affected, firefox74 affected, firefox85 affected, firefox86 affected, firefox87 affected)
People
(Reporter: bmaris, Unassigned)
References
Details
(Keywords: webcompat:site-wait, Whiteboard: site)
Attachments
(3 files)
Affected versions
- Firefox 68.0 RC2
- latest Nightly 69.0a1
Affected platforms
- Windows 7 64bit
- macOS 10.13.6
- Ubuntu 18.04 64bit
Steps to reproduce
- Start Firefox
- Visit https://www.linkedin.com/
- Login
- Hover over the number of comments displayed on a post or number of emoticons (likes etc)
Expected result
- There is some space between the line and text (1 pixel or something)
Actual result
- There is no space between the line and the text for hoverable links.
Regression range
- Not sure if this is a regression or not, I went back to 57.0 RC and this issue was there as well. Will need to find if this is a regression or not ASAP.
Additional notes
- Chrome does not have this issue
- Screenshot submitted shows the issue
- I've noticed that on mac not all hoverable links have the same issue, it might be harder to experience the issue there.
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Comment 2•5 years ago
|
||
Thanks for the test-case Alice! I think they're just relying on Blink / WebKit's bogus text-decoration propagation.
Updated•5 years ago
|
Comment 3•5 years ago
|
||
I went back to Fx 46.0 and this issue was there as well, so this is not a regression.
Comment 4•5 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
Thanks for the test-case Alice! I think they're just relying on Blink / WebKit's bogus text-decoration propagation.
Yes, I think so.
The blink/webkit behavior can be seen more obviously with an example like
data:text/html,<u style="font:50px arial,sans-serif">test
<span style="vertical-align:middle;font-size:.5em">test</span>
<span style="vertical-align:middle;font-size:2em">test
which should have a single continuous underline for the entire u
element (even though it runs through the large text), but in blink/webkit renders separate underlines for each word as if they were independent u
elements.
The proper fix for LinkedIn is probably for them to specify the underlining on the inner element (the one whose vertical-align
may be shifting it relative to its container's baseline), not on the outer containing element.
Comment 5•5 years ago
|
||
The priority flag is not set for this bug.
:jfkthame, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 6•5 years ago
|
||
This isn't really a Firefox bug, it's bad authoring on LinkedIn; see comments 2 and 4.
Updated•5 years ago
|
Comment 7•5 years ago
|
||
I sent an email to LinkedIn on our partner list.
Comment 8•5 years ago
|
||
Comment 9•5 years ago
|
||
Reproduced with a slightly different result on latest beta build 70.0b5 and Nightly build 71.0a1 (2019-09-12) on Windows 7 x64.
See the newly attached file for more info.
Comment 10•5 years ago
|
||
(In reply to Andrei Purice from comment #9)
Reproduced with a slightly different result on latest beta build 70.0b5 and Nightly build 71.0a1 (2019-09-12) on Windows 7 x64.
See the newly attached file for more info.
So now text-decoration-skip-ink is enabled, most of the underline just disappears. The underlying problem is still that they're applying the text-decoration to the wrong element (comment 4).
Comment 11•4 years ago
|
||
This issue was reproducible on Windows 10 with Firefox Nightly version 74.0a1 (2020-01-14) (64-bit) / Beta version 73.0b4 (64-bit) and Release version 72.0.1 (64-bit). Marked as affected.
Comment 12•3 years ago
|
||
This issue is still reproducible on Windows 10 with Firefox Nightly 87.0a1(2021-02-19)(64-bit), Beta 86.0b9 and 85.0.2. Setting the corresponding flags as affected.
Comment 13•3 years ago
|
||
Reproduced on Firefox 78.11.0esr on Win 10x64.
Comment 14•2 years ago
|
||
I can't seem to reproduce this on my side, nor with comments, shares, or the number of emojis.
https://prnt.sc/z4HKJ4bIRokp
https://prnt.sc/ZBqWEqE3q3TS
https://prnt.sc/CTuXHqPDyzmJ
Tested with:
Browser / Version: Firefox Nightly 103.0a1 (2022-06-22)
Operating System: Windows 10 Pro
Bogdan can you still reproduce it?
Comment 15•2 years ago
|
||
I could not reproduce this issue on Nightly 103.0a1(2022-06-23) on Windows 10 x64, Ubuntu 22.04 or macOS 11.
Closing this since it seems to be fixed. Please re-open if the issue is encountered again.
Description
•