44.11 KB, application/zip
1.33 KB, patch
|Details | Diff | Splinter Review|
111.04 KB, application/zip
1.29 MB, application/zip
954 bytes, patch
|Details | Diff | Splinter Review|
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.
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: --- → ?
Keywords: regression, testcase
OS: Unspecified → All
Hardware: Unspecified → All
Version: 45 Branch → 43 Branch
Tracking since this is a recent regression.
tracking-firefox43: ? → +
tracking-firefox44: --- → +
tracking-firefox45: --- → +
Created attachment 8692280 [details] [diff] [review] Skip visible checking for Extend3D frames during building layers
Hi Paul, could you check this patch if it fixes the problem?
(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.
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?
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
Paul, I think the patch at bug 1230072. Please try it!
Flags: needinfo?(tlee) → needinfo?(padenot)
I think it's good now, thanks !
Paul had confirmed bug 1230072 fixes the problem.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
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
Resolution: FIXED → ---
Target Milestone: mozilla46 → ---
See comment 10~12. Ryan, do you mean that bug 1230072 is not working for the problem here?
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?
(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.
Yes, this testcase works properly on 46 and 47 now.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago → 3 years ago
status-firefox46: affected → fixed
status-firefox47: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
You need to log in before you can comment on or make changes to this bug.