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

Status: RESOLVED FIXED

(Core :: Widget, defect)

Description

[Jack W]

Attachment: 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.

Comment 1

[Peter Magyari (Desktop QA)]

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: https://www.mozilla.org/en-US/firefox/channel/desktop/

Thank you for reporting!

Comment 2

[Jack W]

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

Comment 3

[Emilio Cobos Álvarez (:emilio)]

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....

Comment 5

[Daniel Holbert [:dholbert]]

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...

Comment 6

[Daniel Holbert [:dholbert]]

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 \
  -a https://bug1709309.bmoattachments.org/attachment.cgi?id=9221155

Comment 7

[Daniel Holbert [:dholbert]]

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.

Comment 8

[Daniel Holbert [:dholbert]]

mozregression for when this started happening (using the command from comment 6 but without "--launch"):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5a6195f76a1181d70e42deda36b4250a9772c603&tochange=e16ad489f8d20ddf6805d3d941227ba27f353b13

--> 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)

Comment 9

[Daniel Holbert [:dholbert]]

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 \
  -a https://bug1709309.bmoattachments.org/attachment.cgi?id=9221155

(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.

Comment 10

[Matt Woodrow (:mattwoodrow)]

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