Open Bug 1563715 Opened 2 years ago Updated 6 months ago

Hoverable comments link from linkedin have no space between word and line

Categories

(Web Compatibility :: Desktop, 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)

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: bogdan_maris, 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.

You need to log in before you can comment on or make changes to this bug.