Closed Bug 1563715 Opened 5 years ago Closed 2 years ago

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)

RESOLVED WORKSFORME
Tracking Status
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

  1. Start Firefox
  2. Visit https://www.linkedin.com/
  3. Login
  4. 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.
Has Regression Range: --- → no
Attached file reduced html
See Also: → 1436801

Thanks for the test-case Alice! I think they're just relying on Blink / WebKit's bogus text-decoration propagation.

Component: Layout: Block and Inline → Layout: Text and Fonts

I went back to Fx 46.0 and this issue was there as well, so this is not a regression.

Has Regression Range: no → ---

(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.

The priority flag is not set for this bug.
:jfkthame, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jfkthame)

This isn't really a Firefox bug, it's bad authoring on LinkedIn; see comments 2 and 4.

Component: Layout: Text and Fonts → Desktop
Flags: needinfo?(jfkthame)
Product: Core → Web Compatibility
Priority: -- → P3

I sent an email to LinkedIn on our partner list.

Whiteboard: site
Attached image new result.png

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.

(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).

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.

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.

Reproduced on Firefox 78.11.0esr on Win 10x64.

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?

Flags: needinfo?(bogdan.maris)

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.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(bogdan.maris)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: