Closed Bug 2008478 Opened 8 months ago Closed 15 days ago

List of Red Hat KB article titles renders arrow symbols on top of long article title text

Categories

(Web Compatibility :: Site Reports, defect, P3)

Tracking

(Webcompat Priority:P2, Webcompat Score:4)

RESOLVED FIXED
158 Branch
Webcompat Priority P2
Webcompat Score 4

People

(Reporter: cpeterson, Unassigned)

References

()

Details

(Keywords: webcompat:platform-bug, webcompat:site-report)

User Story

platform:windows,mac,linux,android
impact:significant-visual
configuration:general
affects:all
branch:release
user-impact-score:100

Attachments

(2 files)

Steps to reproduce

  1. In Firefox. load a Red Hat KB article, such as https://developers.redhat.com/articles/2023/02/06/how-improve-application-security-using-fortifysource3
  2. Read the article names in right column and notice the arrow symbol → at the end of the lines.

Expected result

Article names that are long enough to word wrap should show the arrow symbol at the end of the second line, like in Chrome and Safari. See the attached Chrome screenshot.

Actual result

Article names that are long enough to word wrap render the arrow symbol on top of the first line of text. See arrow on top of the letters "io" in the word "fortification" in the attached Firefox screenshot.

This is not a regression. I can reproduce in Firefox versions from many years ago.

This is bug 489100, I think. The arrow is drawn as an absolutely-positioned ::after pseudo-element inside of a relatively-positioned inline-level <a> element.

here's the ::after element:

#rlc .rhd-c-lists__list-item h3 a::after {
	position: absolute;
	bottom: 5px;
	display: inline-block;
	width: 16px;
	height: 13px;
	margin-left: 4px;
	vertical-align: middle;
	content: "";
	background: url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCA0NDggNTEyIiBmaWxsPSIjMDZjIj48IS0tISBGb250IEF3ZXNvbWUgUHJvIDYuNC4yIGJ5IEBmb250YXdlc29tZSAtIGh0dHBzOi8vZm9udGF3ZXNvbWUuY29tIExpY2Vuc2UgLSBodHRwczovL2ZvbnRhd2Vzb21lLmNvbS9saWNlbnNlIChDb21tZXJjaWFsIExpY2Vuc2UpIENvcHlyaWdodCAyMDIzIEZvbnRpY29ucywgSW5jLiAtLT48cGF0aCBkPSJNNDM4LjYgMjc4LjZjMTIuNS0xMi41IDEyLjUtMzIuOCAwLTQ1LjNsLTE2MC0xNjBjLTEyLjUtMTIuNS0zMi44LTEyLjUtNDUuMyAwcy0xMi41IDMyLjggMCA0NS4zTDMzOC44IDIyNCAzMiAyMjRjLTE3LjcgMC0zMiAxNC4zLTMyIDMyczE0LjMgMzIgMzIgMzJsMzA2LjcgMEwyMzMuNCAzOTMuNGMtMTIuNSAxMi41LTEyLjUgMzIuOCAwIDQ1LjNzMzIuOCAxMi41IDQ1LjMgMGwxNjAtMTYweiIvPjwvc3ZnPgo=)no-repeat;
}
Component: Layout: Text and Fonts → Site Reports
Depends on: 489100
Product: Core → Web Compatibility
Severity: -- → S3
User Story: (updated)
Webcompat Priority: --- → P3
Webcompat Score: --- → 3
Priority: -- → P3
User Story: (updated)
Webcompat Priority: P3 → P2
Webcompat Score: 3 → 4

I see the expected behavior with layout.abspos.fragment-aware-inline-cb.enabled=true. The arrow symbol → is at the end of the article names. We'll flip the pref by default in bug 2041551.

Status: NEW → RESOLVED
Closed: 4 months ago
User Story: (updated)
No longer depends on: 489100
Duplicate of bug: 489100
Resolution: --- → DUPLICATE

Reopening the bug and making it depend on bug 2041551.

Status: RESOLVED → REOPENED
Depends on: 489100, 2041551
No longer duplicate of bug: 489100
Resolution: DUPLICATE → ---

Verified, the issue no longer reproduces.

Tested with:

  • Browser / Version: Firefox Nightly 158.0a1 (2026-09-13)
  • Operating System: Windows 10
Status: REOPENED → RESOLVED
Closed: 4 months ago → 15 days ago
Resolution: --- → FIXED
Target Milestone: --- → 158 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: