Closed Bug 1704386 Opened 3 years ago Closed 3 years ago

Form elements with opacity <=0.001 are rendered with opacity 1


(Core :: Widget, defect)

Firefox 88



Tracking Status
firefox-esr78 --- unaffected
firefox87 --- unaffected
firefox88 --- wontfix
firefox89 --- unaffected


(Reporter: jackwickham, Unassigned)




(Keywords: regression)


(1 file)

Attached file opacity bug.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

Style an <input> element with opacity: 0.001 (or any 0 < value <= 0.001).

I experienced this on a site that is using radio/checkbox inputs with opacity 0.000001 to apply custom styling without breaking any default behaviour/accessibility.

Actual results:

The input is rendered as fully opaque (opacity 1)

Expected results:

The input is rendered as essentially fully transparent (opacity 0.001). It worked correctly in FF 87, and in Chrome.

Hi Jack,

I was able to reproduce your issue on the latest Beta 88 (20210412175251) on Ubuntu 20.04, the input was rendered fully opaque with "0.001" opacity

However, the issue does not occur on Firefox Nightly 89.0a1.
Could you please also confirm this? You can download Nightly 89.0a1 from:

Thank you for reporting!

Component: Untriaged → Layout: Form Controls
Ever confirmed: true
Flags: needinfo?(jackwickham)
OS: Unspecified → Linux
Product: Firefox → Core

Yeah I'm seeing the same - broken in 88, works in 89.

Flags: needinfo?(jackwickham)

I can repro this on beta, and widget.non-native-theme.enabled=true (which is shipping in 89) fixes it. But there has to be something else, because on nightly flipping that doesn't cause the issue...

None of the nightlies I've tried (including 88 of course) have shown the issue, but I'd be super curious to know what broke-and-then-fixed this....

Component: Layout: Form Controls → Widget

I can reproduce in Firefox 88 on Linux (with Wayland, not sure if that matters), only if I force WebRender to be disabled (at about:config, setting gfx.webrender.force-disabled to true).

So there may be some WebRender-enabled/disabledness dependency here...

I can reproduce in mozregression-launched-nightly with this command:

mozregression --pref "gfx.webrender.force-disabled:true" "widget.non-native-theme.enabled:false" \
  --launch 2021-04-01 \

That command uses 2021-04-01 but I can also reproduce the bug if I swap in today's date (2021-05-10). So this persists to current Nightly, with those pref settings from the command in comment 6.

mozregression for when this started happening (using the command from comment 6 but without "--launch"):

--> Regression from Bug 1694248, i.e. this was a bug with our non-"off-main-thread-painting" codepath, exposed by the fact that we've now switched to using that codepath (for non-webrender configurations)

I can reproduce at least as far back as 2020-09-01 if I add the OMTP-disabling pref assignment to my mozregression command:

mozregression --pref "layers.omtp.enabled:false" "gfx.webrender.force-disabled:true" "widget.non-native-theme.enabled:false" \
  --launch 2020-09-01 \

(If I go another month earlier, the tab crashes, and it does for the few years before that too; presumably there was some crash bug with the non-OMTP codepath before that.)

So: from a user's perspective, this is a regression from bug 1694248, but really it seems like this was a latent bug in the non-omtp codepath, which was just recently revealed by us turning off OMTP. And this will go away once all users are on WebRender (or the WebRender software fallback). i.e. I expect this is a "fixed by webrender" bug which won't get a separate fix of its own.

ni=mattwoodrow to confirm that this makes sense & to see if there's anything else that needs to be done here.

Depends on: fixed-by-webrender
Flags: needinfo?(matt.woodrow)
Regressed by: 1694248
Has Regression Range: --- → yes

Yeah, I don't think we'll rush to fix this, since it's becoming a very rare config.

Flags: needinfo?(matt.woodrow)
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.