Transparent canvas makes transparent element underneath disappear

RESOLVED FIXED in Firefox 46

Status

()

RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: padenot, Assigned: sinker)

Tracking

({regression, testcase})

43 Branch
mozilla47
regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox41 unaffected, firefox42 unaffected, firefox43+ unaffected, firefox44+ unaffected, firefox45+ unaffected, firefox46 fixed, firefox47 fixed, firefox-esr38 unaffected)

Details

(Whiteboard: [gfx-noted])

Attachments

(5 attachments)

(Reporter)

Description

3 years ago
STR:
- Download and unzip the test case
- Open index.html from the filesystem
- Click the "Do it" button

Expected:
- The semi-transparent canvas is shown, the text is visible

Actual:
- The canvas is shown, the text is hidden

Activating layers border with the pref:
- In Firefox 41 there is two layers, one for the text, one for the canvas. This seems expected.
- In Firefox 45, there is only a layer for the canvas, and the text disappears.

Talking to nical, he told me to activate border layers, and told me there should be a layer for the text and the canvas.

Additionally, looking at the bottom of `js/talk.js`, there is a line that can be commented. It was the thing that triggered the issue for me. This is originally a slidedeck written with reveal.js, so there are (potentially 3d) transforms everywhere.
(Reporter)

Comment 1

3 years ago
Created attachment 8684893 [details]
testcase.zip

Simply unzip and open index.html from the filesystem. The interesting bits are in `index.html` and `js/talk.js`. I can repro on OSX and Linux.
[Tracking Requested - why for this release]: new regression introduced in Firefox 43 by bug 1097464.

mozilla-central
===============
Last good revision: 11dc79e232110ba6de5179e46dfbda77b52a88c3 (2015-09-18)
First bad revision: 4313752f69956ae248bd4e7ff3913c8dd4252698 (2015-09-19)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=11dc79e232110ba6de5179e46dfbda77b52a88c3&tochange=4313752f69956ae248bd4e7ff3913c8dd4252698

mozilla-inbound
===============
Last good revision: 7641104770a80015e63597b58cb312fefcbd9ab4
First bad revision: 621ab19e86db28c38bbbf9119fbf6831ea344c54
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7641104770a80015e63597b58cb312fefcbd9ab4&tochange=621ab19e86db28c38bbbf9119fbf6831ea344c54
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox41: --- → unaffected
status-firefox42: --- → unaffected
status-firefox43: --- → affected
status-firefox44: --- → affected
status-firefox-esr38: --- → unaffected
tracking-firefox43: --- → ?
Flags: needinfo?(tlee)
Keywords: regression, testcase
OS: Unspecified → All
Hardware: Unspecified → All
Whiteboard: [gfx-noted]
Version: 45 Branch → 43 Branch
(Assignee)

Updated

3 years ago
Assignee: nobody → tlee
Flags: needinfo?(tlee)
Tracking since this is a recent regression.
tracking-firefox43: ? → +
tracking-firefox44: --- → +
tracking-firefox45: --- → +
(Assignee)

Comment 4

3 years ago
Created attachment 8692280 [details] [diff] [review]
Skip visible checking for Extend3D frames during building layers
(Assignee)

Comment 5

3 years ago
Hi Paul, could you check this patch if it fixes the problem?
Flags: needinfo?(padenot)
(Reporter)

Comment 6

3 years ago
(In reply to Thinker Li [:sinker] from comment #5)
> Hi Paul, could you check this patch if it fixes the problem?

It does not, and it kind of makes thing worse, it invalidates even less.
Flags: needinfo?(padenot)
(Assignee)

Comment 7

3 years ago
Created attachment 8693170 [details]
layerscope.zip

Paul, this is layerscope file that I have got on my linux machine.  It works for me.  Could you capture a layerscope file on you machine too?
Flags: needinfo?(padenot)
(Reporter)

Comment 8

3 years ago
Created attachment 8693534 [details]
layerscope of the issue

Here is a layerscope, I think the issue is repro-ed on the last couple frames.

I had more luck reproducing this issue when`layers.force-enabled` is not set to true, although I've been able to rarely repro with it set to true.
Flags: needinfo?(padenot) → needinfo?(tlee)
Too late to make it into 43 as we are now heading into beta 9.
status-firefox43: affected → wontfix
(Assignee)

Comment 10

3 years ago
Paul, I think the patch at bug 1230072.  Please try it!
Flags: needinfo?(tlee) → needinfo?(padenot)
(Reporter)

Comment 11

3 years ago
I think it's good now, thanks !
Flags: needinfo?(padenot)
(Assignee)

Updated

3 years ago
Depends on: 1230072
(Assignee)

Comment 12

3 years ago
Paul had confirmed bug 1230072 fixes the problem.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
No longer depends on: 1230072
Depends on: 1230780
From this point forward in Beta44 cycle (a week away from RC), we are only accepting fixes for critical recent regressions, sec and stability fixes. This issue while valid does not meet that bar. wontfix for Fx44.
status-firefox44: affected → wontfix
status-firefox46: --- → fixed
Target Milestone: --- → mozilla46
The change that caused this regression was backed out from Firefox 45. A current Developer Edition build should now work correctly, or you can wait until 45 goes to Beta some time next week.

https://hg.mozilla.org/releases/mozilla-aurora/rev/64ec448f156d

That said, the testcase still appears to reproduce the original problem for me on a current Nightly build, so I'm reopening it.
Status: RESOLVED → REOPENED
status-firefox43: wontfix → unaffected
status-firefox44: wontfix → unaffected
status-firefox45: affected → unaffected
status-firefox46: fixed → affected
Flags: needinfo?(tlee)
Resolution: FIXED → ---
Target Milestone: mozilla46 → ---
(Assignee)

Comment 15

3 years ago
See comment 10~12.

Ryan, do you mean that bug 1230072 is not working for the problem here?
Flags: needinfo?(tlee)
Yes, I'm saying that the testcase is opaque on a current m-c build, but properly transparent on Aurora. I tested the nightly build immediately after bug 1230780 landed (since that's what bug 1230072 got duped to) and it still reproduces.

Maybe the patch from bug 1230072 is still needed?
(Assignee)

Comment 17

3 years ago
Created attachment 8714227 [details] [diff] [review]
extend3d-range.diff
(Assignee)

Comment 18

3 years ago
(In reply to Thinker Li [:sinker] from comment #17)
> Created attachment 8714227 [details] [diff] [review]
> extend3d-range.diff

Ryan, this patch should fix the problem.  But, bug 1229317 would cover the change of this patch too.  So, if you can confirm this patch fix the problem, then this bug can depend on bug 1229317.
Yes, this patch fixes the attached testcase.
status-firefox47: --- → affected
Depends on: 1229317
Is this fixed now, with bug 1229317, or do we need additional code?  Bug 1229317 landed on central on 2/7 and got uplifted to aurora 46 on 2/26.
Flags: needinfo?(tlee)
Flags: needinfo?(ryanvm)
Flags: needinfo?(matt.woodrow)
Yes, this testcase works properly on 46 and 47 now.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
status-firefox46: affected → fixed
status-firefox47: affected → fixed
Flags: needinfo?(tlee)
Flags: needinfo?(ryanvm)
Flags: needinfo?(matt.woodrow)
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
You need to log in before you can comment on or make changes to this bug.