Closed
Bug 1266380
Opened 7 years ago
Closed 7 years ago
Regression: 3D transformed elements disappear when parent have filter+perspective applied
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
FIXED
mozilla49
People
(Reporter: vincent, Assigned: mattwoodrow)
References
Details
(Keywords: regression, Whiteboard: [gfx-noted])
Attachments
(3 files)
2.89 KB,
patch
|
jrmuizel
:
review+
ritu
:
approval-mozilla-aurora+
ritu
:
approval-mozilla-beta-
|
Details | Diff | Splinter Review |
454 bytes,
text/html
|
Details | |
1.30 KB,
patch
|
sinker
:
review+
|
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.
Updated•7 years ago
|
Comment 1•7 years ago
|
||
> 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
Blocks: 1252324
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Ever confirmed: true
Keywords: regressionwindow-wanted
Comment 2•7 years ago
|
||
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)
Comment 3•7 years ago
|
||
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
Flags: needinfo?(matt.woodrow)
Comment 4•7 years ago
|
||
A simplified version of the test case that can be run locally.
Updated•7 years ago
|
Attachment #8744536 -
Flags: review?(jmuizelaar) → review+
Updated•7 years ago
|
Keywords: leave-open
Whiteboard: [gfx-noted]
Comment 6•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4f8e510a1b7f
Assignee | ||
Comment 7•7 years ago
|
||
Flags: needinfo?(matt.woodrow)
Attachment #8745821 -
Flags: review?(tlee)
Updated•7 years ago
|
Attachment #8745821 -
Flags: review?(tlee) → review+
Assignee | ||
Updated•7 years ago
|
Keywords: leave-open
Comment 9•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/d3b2f4b2e016
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox49:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
![]() |
||
Comment 10•7 years ago
|
||
[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?
Comment 11•7 years ago
|
||
And to 47, if possible.
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
Assignee | ||
Updated•7 years ago
|
status-firefox47:
--- → affected
tracking-firefox47:
--- → ?
Assignee | ||
Comment 12•7 years ago
|
||
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
Attachment #8744536 -
Flags: approval-mozilla-beta?
Attachment #8744536 -
Flags: approval-mozilla-aurora?
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!
Flags: needinfo?(milan)
Flags: needinfo?(bugs)
Flags: needinfo?(bugmail.mozilla)
Based on comment 3, this is actually in 45, so I'd say keep it out of beta given the timing.
Flags: needinfo?(milan)
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-
Attachment #8744536 -
Flags: approval-mozilla-beta?
Attachment #8744536 -
Flags: approval-mozilla-beta-
Attachment #8744536 -
Flags: approval-mozilla-aurora?
Attachment #8744536 -
Flags: approval-mozilla-aurora+
Updated•7 years ago
|
Flags: needinfo?(bugmail.mozilla)
Comment 17•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/036020df2de8
Updated•7 years ago
|
Updated•7 years ago
|
Flags: needinfo?(bugs)
Comment 19•7 years ago
|
||
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.
Description
•