@Talkie_APP hi from Firefox! Bug report: our users noticed your website shows unwanted scrollbars in Firefox. There's a simple fix: consider hiding your scrollbars with `* { scrollbar-width: none }` instead of (or alongside) your `::-webkit-scrollbar { display: none; }`. Thanks!

Confirmed fixed on my end as well. Thanks so much for taking care of this!

Thanks!

here's a screenshot from the bug, too -- top half is the super-blue" bad" result we're hoping to avoid, bottom half is the "good/expected" rendering.

The CSS in question is in bugzilla.mozilla.org/show_bu… . Hoping someone on your team can take a look and remove it - thanks in advance!

But Firefox Nightly includes a compat change that we needed to fix issues on other sites that makes us start successfully parsing more -webkit-prefixed CSS selectors, which makes us pass both #1 and #2, and so we actually honor the CSS and turn the widget blue.

Instaread's inactive CSS is basically: "browser, can you: 1. ...parse this -moz-prefixed CSS selector? 2. ...and parse this -webkit-prefixed CSS selector? If so, turn the widget blue." Chrome/Safari fail #1. Firefox historically fails #2. Hence, the CSS is effectively inactive.

For now this only affects Firefox Nightly, but the change in question will reach our release version in a month or two, and we're hoping to address this before then. We're exploring options on our end, but if you can delete this bit of inactive CSS, that's the easiest fix. :)

@rahulific hi from Firefox! We're looking for help from Instaread, on an issue that makes your embedded audio widget solid-blue for Firefox Nightly users. Details in bugzil.la/2044435 - tl;dr you've got inactive CSS that breaks stuff if it's parsed (and we now parse it).

ah, thanks for that clarification. So the perf benefit here is more about keeping the animation looking smooth, even in the presence of unrelated main-thread jank. Makes sense!

Interesting. Do you have cases where this noticeably improves responsiveness, or is this mostly about reducing power consumption from cpu wakeups? In any case I filed bugzilla.mozilla.org/show_bu… to explore this in Firefox. No promises on anyone working on it right away though. :)

It's nearly ready - took a back seat to some other projects. Hoping to finish it off within the next month (on Nightly, and then hopefully reaching release within 2 months of that)

Looks like it's fixed now - thanks for the help with this!

@zitomerjeff I wonder if you might be able to help direct this to someone at Human who could help us out and get Firefox users unblocked? Thanks!

@SecureWithHUMAN Hi - we (Firefox) have found that Human's captcha is rejecting Firefox users recently (in part related to a change to Firefox's pointer-events code). Could we get your help in getting this addressed? See bugzilla.mozilla.org/show_bu… for more details. Thanks!

@votermapsorg hi! I work on Firefox, and we got a report that your map is broken in Firefox (because it's accidentally depending on an ancient Chrome/Safari bug). The fix is trivial, though: see bugzilla.mozilla.org/show_bu… for two trivial options, if you'd like to fix this. Thanks!

Similar/worse issues in dark theme on desktop browsers with dark color-scheme, actually -- here's a screenshot of gray text on gray background (entirely invisible):

@Caltrain hi! Website bug for you: schedule is quite hard to read (white text on light gray) with the site's dark theme (activated via user dark-theme-preference in e.g. Android system settings, or browser settings). Issue reproduces in Firefox and Chrome on Android (at least)

Looks like that's bugzilla.mozilla.org/show_bu…