overflow:clip causes transformZ to stop applying to UI but not to the rendered result
Categories
(Core :: Layout, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | wontfix |
firefox85 | --- | wontfix |
firefox86 | --- | wontfix |
firefox87 | --- | fix-optional |
People
(Reporter: quietpianist-git, Unassigned)
References
Details
(Keywords: regression, regressionwindow-wanted)
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
Steps to reproduce:
Create a div positioned absolutely and transformed such that it's only translated along the Z axis then scaled back on the X and Y axis so that no size change is perceivable. Add a clickable anchor tag to it. Add a parent to the div that has a fixed height, "transform-style: preserve-3d;", and "overflow:clip;". Add a sibling to this div with a fixed height larger than the page. Add a parent to both of these elements with a perspective rule, "height: 100vh;" and "overflow: auto;".
Actual results:
The content should scroll with parallax as the page is scrolled and appear correct, but clicking on the anchor does nothing because the actual clickable area of the anchor is positioned in the location it would've been before being translated along the Z axis.
Expected results:
The clickable part of the anchor tag should reside over the visible part of the anchor tag.
Comment 1•4 years ago
|
||
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=df688b6d4c8d3aa7378a14b6a380c335cc222ce4&tochange=3524c48add1142ccd10b6b114864966ea93b2612
Suspect: Bug 1635473 and Bug 1531609
Comment 2•4 years ago
|
||
Those patches basically renamed -moz-hidden-unscrollable
to clip
, but it seems the problem was pre-existing. I can reproduce it in Firefox 78 with this test-case.
Updated•4 years ago
|
Comment 3•4 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
Created attachment 9200185 [details]
Testcase with -moz-hidden-unscrollable.Those patches basically renamed
-moz-hidden-unscrollable
toclip
, but it seems the problem was pre-existing. I can reproduce it in Firefox 78 with this test-case.
Yes, I can also reproduce the issue on Nightly(20171101101044) with force WebRender enabled.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 4•4 years ago
|
||
I can confirm that I could reproduce this issue on Firefox 78.7 esr, Firefox 85, Firefox 86 beta 4, and Nightly 87.0a1 (when using the test case from Comment 2). I could also reproduce it on older versions like Firefox 60.0.1.
Emilio, considering this is not a recent regression, is it still a candidate for regressionwindow-wanted? If yes, could you please advise on how far should I go with the regression?
Thanks!
Comment 5•4 years ago
|
||
Yeah, having a regression range would be amazing... As for how far to go I don't know, I'd probably try firefox 40-ish... If it still repros there it's probably not worth finding the precise range (or it might not be a regression at all)
Comment 6•4 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)
Yeah, having a regression range would be amazing... As for how far to go I don't know, I'd probably try firefox 40-ish... If it still repros there it's probably not worth finding the precise range (or it might not be a regression at all)
Using the test case from Comment 2, I was able to reproduce the issue all the way to Firefox 35.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
Created attachment 9200185 [details]
Testcase with -moz-hidden-unscrollable.Those patches basically renamed
-moz-hidden-unscrollable
toclip
, but it seems the problem was pre-existing. I can reproduce it in Firefox 78 with this test-case.
Just to note, I thought I had tested with overflow:hidden
before and got different results which is why I was using clip
, but after testing again the issue apparently also manifests when using hidden
with no apparent difference from clip
, so the issue does not appear to be specific to clip
.
Updated•4 years ago
|
Comment 8•4 years ago
|
||
FWIW, the testcase here also has somewhat different behavior in Safari vs Chrome. I haven't studied it further to figure out which (if either) is more correct.
Description
•