2066814 - chat.qwen.ai - Selected text in AI responses is not highlighted

Status: VERIFIED FIXED

(Core :: Layout: Text and Fonts, defect, P2)

Description

[Raul Bucata]

Environment:
Operating system: Linux and Windows
Firefox version: Firefox 156.0a1 (nightly)

Preconditions:

• Clean profile

Steps to Reproduce:

1. Navigate to https://chat.qwen.ai/
2. Send any prompt and wait for the response to render
3. Select part of the response text with the mouse and observe

Expected Result:
The selected text should be visibly highlighted.

Actual Result:
The selected text shows no highlight, although it can still be copied.

Notes:

• Reproducible on the latest Firefox Release and Nightly
• Reproducible regardless of the ETP setting
• Works as expected using Chrome

---

Created from webcompat-user-report:3435b6a6-6e11-4182-8290-7c07715f5f1c

Comment 1

[Raul Bucata]

Additional information from the reporter:

• The reporter states that selected text highlighting works as expected in Firefox 153.0.3, which suggests this may be a regression.
• The reporter worked around the issue with the Stylus extension using the following css rule, which restores the highlight:

.response-message-content ::selection { background: yellow; color: black; }

Comment 2

[Raul Bucata]

Attachment: chr vs ff.mp4

Comment 3

[AutoWebCompat]

Attachment: Reproduction script generated by autowebcompat bot

On chat.qwen.ai, selecting text inside a rendered AI answer paints no selection highlight in Firefox — the text is selected and copyable, but the answer area looks completely unchanged. Chrome paints the usual blue selection highlight over the same text. In Firefox the missing highlight extends to other text on the conversation page as well.

Comment 4

[AutoWebCompat]

Attachment: Screenshot generated by autowebcompat bot

Comment 5

[AutoWebCompat]

Root cause analysis generated by autowebcompat bot:

Pure CSS engine difference in how ::selection styling interacts with the UA default selection highlight — no UA sniffing or browser-specific codepath is involved.

chat.qwen.ai's main.css (https://assets.alicdn.com/g/qwenweb/qwen-chat-fe/0.2.87/css/main.css) contains exactly one selection rule for answer text:

.response-message-content ::selection { border-radius: 2px; padding: 4px 0 }

Per CSS Pseudo-Elements Level 4 (§ "Styling Highlights", https://www.w3.org/TR/css-pseudo-4/#highlight-styling) only a restricted set of properties applies to highlight pseudo-elements — color, background-color, the text-decoration properties, text-shadow, -webkit-text-stroke, etc. border-radius and padding are NOT in that set and "must be ignored". So this rule contributes no declarations at all and the UA default highlight (§ "Default styles" / https://www.w3.org/TR/css-pseudo-4/#selectordef-selection, effectively ::selection { color: HighlightText; background-color: Highlight } at UA origin) should still paint.

Blink does that: it drops the non-applicable declarations, is left with no author highlight style, and keeps painting the default highlight background.

Gecko instead appears to decide on selector match rather than on surviving declarations: because some author ::selection rule matched the text, it resolves the selection style from that rule, and background-color there falls back to its initial value transparent. Result: no selection background is painted over any text inside .response-message-content. The text is still selected and copyable (Selection.toString() returns it, Ctrl+C works) — there is simply no visual feedback.

Note the narrower shape of the bug, confirmed by the testcase: once an author ::selection rule with an applicable declaration matches (e.g. ::selection { color: black } with no background-color), BOTH engines drop the default background. The divergence is specific to a ::selection rule whose declarations are all inapplicable to highlight pseudo-elements — Blink treats it as "no author style", Gecko treats it as "author style with transparent background".

Evidence:

Site CSS: curl of https://assets.alicdn.com/g/qwenweb/qwen-chat-fe/0.2.87/css/main.css contains, verbatim and as the only selection rule for answer text:
.response-message-content ::selection{border-radius:2px;padding:4px 0}
(The site's stylesheets are cross-origin, so document.styleSheets[].cssRules is inaccessible from the page in both browsers — the rule had to be read from the fetched file.)

Live-site probe (identical script run in both browsers on https://chat.qwen.ai/, no login, no pref changes): injected a fixed-position box containing (a) a CONTROL paragraph outside any .response-message-content and (b) a TARGET paragraph wrapped in <div class="response-message-content">, then selected both with one Range (sel.toString().length === 148 in both browsers) and screenshotted.

• Chrome: BOTH lines painted with the blue selection highlight.
• Firefox Nightly: CONTROL line painted blue; TARGET line inside .response-message-content painted with NO highlight at all.
  This shows the divergence comes purely from the site's ::selection rule matching, not from anything about the streamed answer markup.

Reduced testcase /app/diagnosis/testcase=a5qb9f39.html (loaded from file:// in both browsers, one Range selecting all four cases on load, screenshot compared):
case 1 — no ::selection rule → FF: blue Chrome: blue (same)
case 2 — ::selection { border-radius:2px; padding:4px 0 } → FF: NONE Chrome: blue ** DIVERGES **
case 3 — ::selection { color: black } → FF: NONE Chrome: NONE (same)
case 4 — ::selection { background: yellow; color: black } → FF: yellow Chrome: yellow (same)
Case 2 is the site's rule verbatim and reproduces the reported breakage. Case 3 rules out "Firefox always drops the default background when ::selection is styled" — both engines do that; the difference is only for rules whose declarations are all inapplicable to a highlight pseudo-element.

No console errors, no failed network requests, and no UA-dependent branching were involved.

Comment 6

[AutoWebCompat]

Attachment: Reduced testcase generated by autowebcompat bot

Comment 7

[Emilio Cobos Álvarez [:emilio]]

::selection { border-radius: revert !important }

Would work as an intervention.

Comment 8

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2058134

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Attachment: Test-case that shows that chrome imposes property restrictions on highlights.

So there are two ways to fix it:

• Add tracking for background-color specifically.
• Reuse the property restrictions mechanism so that border-related properties can never be set on highlight pseudos.

Seems Chrome does the later, I'm ok with that.

Comment 10

[BMO Github Automation]

Attachment: [mozilla-firefox/firefox] Bug 2066814 - Restrict the properties that highlight pseudos get at cascade time. r=#style (#357)

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b9c51f59c975
https://hg.mozilla.org/integration/autoland/rev/9de51bc60b4a
Restrict the properties that highlight pseudos get at cascade time. r=dshin

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/62468 for changes under testing/web-platform/tests

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/1afbd2232418
https://hg.mozilla.org/integration/autoland/rev/7fcaf0d7f7e8
Annotate forced-colors-mode-14.html as an expected failure on windows.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/fdc12896d419
https://hg.mozilla.org/integration/autoland/rev/6b9d43d93949
forced-colors-mode-14.html actually only passes on linux.

Comment 15

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/9de51bc60b4a
https://hg.mozilla.org/mozilla-central/rev/7fcaf0d7f7e8
https://hg.mozilla.org/mozilla-central/rev/6b9d43d93949

Comment 16

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected, along with ESR.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta and ESR approvals.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox156 and the ESR status flag(s) to wontfix.

For more information, please visit BugBot documentation.

Comment 17

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2066814 - Restrict the properties that highlight pseudos get at cascade time.

Matches Chrome and the spec in terms of em / lh units etc, and prevents
border-radius to set the border-background flag without extra tracking.

Pull request: https://github.com/mozilla-firefox/firefox/pull/357

Comment 18

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Regression in high profile site
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: Matches what Chrome does.
• String changes made/needed?: none
• Is Android affected?: yes

Comment 19

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2066814 - Restrict the properties that highlight pseudos get at cascade time.

Matches Chrome and the spec in terms of em / lh units etc, and prevents
border-radius to set the border-background flag without extra tracking.

Pull request: https://github.com/mozilla-firefox/firefox/pull/357

Comment 20

[Phabricator Automation]

firefox-esr153 Uplift Approval Request

• User impact if declined/Reason for urgency: Regression in high profile site
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: Matches what Chrome does.
• String changes made/needed?: none
• Is Android affected?: yes

Comment 21

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/9cfc56af926b
https://hg.mozilla.org/releases/mozilla-beta/rev/e977d3de9fce

Comment 22

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr153/rev/45e6eba27962

Comment 23

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 24

[Monica Chiorean]

I was able to reproduce on Win11x64 using FF build 155.0 only with attached reduced test/script.
Verified that on Win11x64/ Ubuntu 24.04 using FF builds 157.0a1 I get same settings as on Chrome are displayed. Waiting for next Beta to check on Beta.

Comment 25

[Monica Chiorean]

Verified that on Win11x64/ Ubuntu 24.04 using FF build 156.0b4 I get same settings as on Chrome.

Comment 26

[Monica Chiorean]

Verified that on Win11x64/ Mac 15.5 using FF build 153.3.0esr I get same settings as on Chrome.