2044435 - Instaread audio-widget on various sites (e.g. thehill.com) unexpectedly renders with blue background, due to Firefox now parsing a selector list that we previously rejected (and which Chrome rejects) with a mix of moz and webkit prefixed syntax

Status: VERIFIED FIXED

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

Description

[Daniel Holbert [:dholbert]]

STR:

1. Visit https://thehill.com/homenews/campaign/5903751-becerra-leads-california-gubernatorial-race/
2. Scroll down if needed, to see the audio widget just before the article text ("Listen to audio version of this article")

ACTUAL RESULTS:
The audio widget has a blue background.

EXPECTED RESULTS:
Just the play button should have a blue background.

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6aba59ba93db4d07f01cf07c3e691b1fd027b9ad&tochange=2e6f17e309c8eaa7f449014b24f3fb6fdb2a9607

Chrome gives EXPECTED RESULTS.
Firefox 151 gives EXPECTED RESULTS.
Firefox 152beta and Nightly 153 give ACTUAL RESULTS (makes sense given the regression range).

On the regressor bug 2036615 comment 2, there's discussion of another regression where layout.css.fake-webkit-scrollbar.enabled came into play, but that pref isn't relevant here (toggling that pref doesn't make the problem go away).

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot (Nightly153/Beta 152 rendering on top, Release 151 rendering on bottom)

Comment 2

[Daniel Holbert [:dholbert]]

Here's a direct link to the widget here -- it's just in an iframe on the article page, but it also can be loaded (and reproduces the bug) directly:
https://player.instaread.co/player?article=becerra-holds-6-point-lead-as-californians-prepare-to-vote-for-governor&publication=thehill&article_url=https%3A%2F%2Fthehill.com%2Fhomenews%2Fcampaign%2F5903751-becerra-leads-california-gubernatorial-race&version=1780424400000

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (from running testcase-reducer on a root node in the iframe)

Comment 4

[Daniel Holbert [:dholbert]]

This is the relevant CSS rule:

      .provider-primary-border,
      .button-container:hover .spinner,
      .button-container:hover .spinner:before,
      .button-container-selected .provider-primary-selected,
      .button-container-selected .provider-primary-border-small,
      .provider-primary-seekbar::-webkit-slider-thumb,
      .provider-primary-seekbar::-moz-range-thumb,
      .provider-primary-seekbar::-moz-range-progress,
      .button-container:hover .circular-button,
      .button-container:hover .spinner:after,
      .button-container:hover .speed-text-hover,
      .widget-ad-container,
      .provider-primary-seekbar::-moz-range-progress,
      input[type="range"]::-webkit-slider-thumb,
      input[type="range"]::-moz-range-thumb,
      .provider-primary-seekbar::-webkit-slider-thumb:hover,
      .provider-primary-seekbar::-moz-range-thumb:hover,
      .provider-primary-seekbar::-moz-range-thumb,
      .provider-secondary-background {
          background-color: var(--primary-color);
      }

There's a root element that has class provider-secondary-background which the last selector there is matching; and
--primary-color there is blue.

But Firefox release and Chrome seem to ignore this rule entirely, whereas Firefox Nightly/beta is honoring it.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (demonstrates difference between unaffected vs. affected Firefox)

It looks like this is the selector that makes Firefox Release and Chrome reject the rest of the rule (disregarding the selector that would otherwise match):

    .provider-primary-seekbar::-webkit-slider-thumb:hover,

The site is accidentally relying on that selector causing the whole rule to be ignored.

Here's a reduced testcase to exercise that, which renders with white background in Firefox release and Chrome vs. red in Firefox beta 152 and nightly 153.

Comment 6

[Daniel Holbert [:dholbert]]

EDIT: sorry, Chrome matches Nightly on testcase 2 (but Firefox release does not). So testcase 2 exercises the difference between release and Nightly, but not between Chrome and Nightly.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

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

:emilio, since you are the author of the regressor, bug 2036615, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

Yeah so chrome ignores that rule because of the ::-moz- selectors, ugh...

Not sure I have a great idea for this one tbh.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (red in Firefox 152-153, no red in Chrome or Firefox 151)

OK, here's a better reduction of the CSS that I quoted in comment 4.

• Firefox 151 and earlier doesn't understand the ::-webkit-slider-thumb:hover selector and rejects the rule for that reason.
• Chrome doesn't understand the moz-prefixed selectors, e.g. ::-moz-range-thumb, and rejects the rule for that reason.
• Firefox 152 and newer (after the regression) understands all of the selectors and hence fully parses the rule and applies the background to the .test element as-instructed. :-/

(And in this case the site is inadvertently depending on the rule being rejected.)

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #8)

Not sure I have a great idea for this one tbh.

Worst-case we could ship an intervention and try to get in touch with the site, I guess? (targeting https://player.instaread.co/ )

I'm going to morph this to a webcompat site-report, in the interests of maybe shipping an intervention. This probably affects many news sites that use this Instaread service, but thehill is a prominent one, so I'll fill that in as the URL here for commensurate webcompat-impact-scoring.

I found at least one other news site that uses the same widget and is also affected:
https://www.inkfreenews.com/2026/06/02/historic-new-harmony-named-a-blue-star-museum/
Direct link to the embedded instaread iframe document:
https://player.instaread.co/player?article=historic-new-harmony-named-a-blue-star-museum&article_url=https%3A%2F%2Fwww.inkfreenews.com%2F2026%2F06%2F02%2Fhistoric-new-harmony-named-a-blue-star-museum&publication=inkfreenews&version=1780426200000

Comment 11

[Daniel Holbert [:dholbert]]

I spun off bug 2044449 as a platform-bug here to represent the behavior-change / implementation-difference.

Comment 12

[Daniel Holbert [:dholbert]]

Relevant stylesheets here, for the news sites that I already linked above:
thehill.com: https://player.instaread.co/css/standard_hill_player.1.0.1.css
inkfreenews.com: https://player.instaread.co/css/standard_new_short_player.1.0.0.css

Here are some other affected news sites, from skimming https://x.com/Instareads which publicizes sites that are using this embedded iframe:

Iowa's Pulse:
Article: https://iowaspulse.com/iowa-manufacturing-investment-big-tax-credits/
iframe inner document
Stylesheet: https://player.instaread.co/css/standard_new_floating_player.1.0.1.css

Star Wars News Net:
Article: https://www.starwarsnewsnet.com/2026/06/the-mandalorian-and-grogu-easter-eggs-and-connections-guide.html
iframe inner document
Stylesheet: https://player.instaread.co/css/zmescience_dark_floating.1.0.0.css

Bedford Independent (UK):
Article: https://www.bedfordindependent.co.uk/bedford-born-connor-tallentire-caps-excellent-us-college-golf-season-with-national-championship-triumph/
iframe inner document
Stylesheet: https://player.instaread.co/css/standard_new_short_player.1.0.0.css

The stylesheets are different, but I think they all have this exact same CSS rule.

I think we could fix the issue with an intervention like this, targeting instaread.co and resetting background-color on this element...

.provider-secondary-background {
          background-color: initial;
 }

Hypothetically if there's some instaread flavor that intentionally sets background-color in a different CSS rule for this element, then this intervention would be a problem.... but maybe in practice they've all got roughly the same setup?

Comment 13

[Daniel Holbert [:dholbert]]

I sent a message to Instaread via their contact-us form on their site, and I'll report back if I hear anything.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Regressing bugs reverted from Beta for 152.0b7.

Comment 15

[Emilio Cobos Álvarez [:emilio]]

[Tracking Requested - why for this release]: Let's revisit this in a bit after outreach has happened.

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #13)

I sent a message to Instaread via their contact-us form on their site, and I'll report back if I hear anything.

I also posted to one of their co-founders on Twitter/X: https://x.com/CodingExon/status/2062294831721042398

Comment 17

[Daniel Holbert [:dholbert]]

Got a reply to my tweet - they're going to look into it.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox153 (nightly). However, the bug still isn't assigned and has low severity.

:skyschub, could you please find an assignee and increase the severity for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 19

[Daniel Holbert [:dholbert]]

(that bugbot notification makes less sense for this component; cancelling ni. In any case, see above; we're hoping and have reason to believe this will be fixed on the site's end)

Comment 20

[Daniel Holbert [:dholbert]]

This seems to be fixed already!

Looking at thehill.com article from comment 0, the audio widget looks correct in Nightly; and I can see that the instaread widget has a new URL for its stylesheet: https://player.instaread.co/css/standard_hill_player.1.0.2.css
(with "1.0.2" instead of "1.0.1" in comment 12)

Checking all the other articles that I linked in comment 12, they all look fine now too. So I think this has been fixed on the site's end.

Comment 21

[Daniel Holbert [:dholbert]]

Ah nice, they sent confirmation that they fixed it in a reply on x.com too:
https://x.com/rahulific/status/2062921061621203135