Closed Bug 1266380 Opened 4 years ago Closed 4 years ago
Regression: 3D transformed elements disappear when parent have filter+perspective applied
2.89 KB, patch
|Details | Diff | Splinter Review|
454 bytes, text/html
1.30 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36 Steps to reproduce: 1. Open this JSBin: http://output.jsbin.com/jusoya in Firefox 48 2. The red square is not visible 3. Remove the `filter` declarations from `.perspective` selector 4. The red square become visible This only occur when an element is 3D transformed AND its parent have CSS `perspective` and `filter` set. Even stranger, remove the `top` and `left` properties from the `.perspective`, and the red square appears, but seems to be transformed weirdly. Actual results: The `filter` property makes elements dissapear. Bug is not present in Firefox 45.0.2 but is in Firefox 48. So it seems to be a regression.
> 11:00.29 INFO: Last good revision: 604a180b6cc0e101eef1f974356b613aa0a40146 > 11:00.29 INFO: First bad revision: 51102a2a44b51fa19ccb8f7504ea07c4a65ebf55 > 11:00.29 INFO: Pushlog: > https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=604a180b6cc0e101eef1f974356b613aa0a40146&tochange=51102a2a44b51fa19ccb8f7504ea07c4a65ebf55 > 11:01.22 INFO: Looks like the following bug has the changes which introduced the regression: > https://bugzilla.mozilla.org/show_bug.cgi?id=1252324
The untransformed draw target is drawn with an offset at bounds.x/y, but this was not factored into the effective transform that is applied to move the untransformed DT snapshot from untransformed space to transformed space. This fixes that and some incidental questionable uses of references on rvalues nearby.
Attachment #8744536 - Flags: review?(jmuizelaar)
So, my patch deals with one part of the regression, but I ran through mozregression twice myself, and the regression actually started with bug 1168263 in the following patch by Matt Woodrow: https://hg.mozilla.org/mozilla-central/rev/7e18014be68d
A simplified version of the test case that can be run locally.
Attachment #8744536 - Flags: review?(jmuizelaar) → review+
Attachment #8745821 - Flags: review?(tlee)
[Tracking Requested - why for this release]: Web page not shown correctly on Aurora48.0a2 with both e10s and HWA disabled. See Bug 1275504 Could you up lift this to 48?
And to 47, if possible.
Assignee: nobody → matt.woodrow
Comment on attachment 8744536 [details] [diff] [review] fix offset of untransformed surface when 3d transforming in BasicLayerManager Approval Request Comment [Feature/regressing bug #]: Bug 1168263 [User impact if declined]:Broken rendering when combining perspective and css filters. [Describe test coverage new/current, TreeHerder]: Manually tested [Risks and why]: Low risk. [String/UUID change made/needed]: None
Hi folks, I am leaning towards wontfixing this for Fx47. We enter RC week on Monday. I am not sure but this regression might already be in Fx46 and we might need to ship another release with it. At this point only issues that might lead to dot-releases are making the cut for Beta uplift. Please let me know if this is a release blocker. Thanks!
Based on comment 3, this is actually in 45, so I'd say keep it out of beta given the timing.
Version: 48 Branch → 45 Branch
Thanks Milan. This is a regression since Fx45, it's too late to take a fix in Beta47.
Comment on attachment 8744536 [details] [diff] [review] fix offset of untransformed surface when 3d transforming in BasicLayerManager Let's uplift to Aurora48, Beta47-
Reproduced with 2016-04-21 Nightly. Verified as fixed across platforms using latest Aurora 48.0a2, 49.0a2.
You need to log in before you can comment on or make changes to this bug.