z-index stack context not working correctly when child iframe is 100% dimensions of parent
Categories
(Core :: DOM: Content Processes, defect)
Tracking
()
People
(Reporter: colinmaxfield, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:96.0) Gecko/20100101 Firefox/96.0
Steps to reproduce:
Our application is setup in a way that there is a parent container of two elements: a drag handle div and an iframe. The z-index and positions of the two are setup in such a way so that the drag handle appears over the iframe allowing you to drag it around. Starting in Firefox 95 (in December 2021) we noticed that the drag handle was no longer working in the same way. The cursor would no longer change to the grab hand and clicking and dragging would not drag the divs around.
At the time of discovering the bug we tested in Firefox Beta (then it was Firefox 96) and the issue didn't exist so we decided to wait for 96 to hit stable. Upon 96 being released however the problem still persisted after the browser updated.
I have created a CodePen that has the same styles (with an additional color for easy viewing) to repro the issue: https://codepen.io/colingm/pen/mdqbawm You will notice that if you open the same pen in Chrome you will notice it behave as expected. It now seems that Firefox Beta is also exhibiting the buggy behavior when it wasn't upon originally testing.
Actual results:
The browser seems to act as if the frame that is under the div is actually on top. Clicks pass straight through to it and cursor styles are not being applied correctly.
Expected results:
The drag handle div is actually placed on top of the iframe and it should be receiving all click events.
|
||
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Navigation' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•4 years ago
|
||
I can reproduce the problem in Nightly98 Windows10.
If fission is disabled, the problem goes away.
|
||
Comment 4•4 years ago
|
||
hsivonen, do you think this is about mouse event targeting or some APZ bug?
I think you've looked at (at least triaged) some of these kinds of issues.
(In reply to Olli Pettay [:smaug] from comment #4)
hsivonen, do you think this is about mouse event targeting or some APZ bug?
I think you've looked at (at least triaged) some of these kinds of issues.
Could be either. Redirecting needinfo to Emilio due to bug 1747409.
|
||
Comment 6•4 years ago
|
||
Seems like a dup of bug 1747409, but it'd be great to have a URL or test-case to confirm.
|
Reporter | |
Comment 7•4 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)
Seems like a dup of bug 1747409, but it'd be great to have a URL or test-case to confirm.
It does seem to be related (at the very least the click part). I imagine the cursor: grab style not being applied correctly would be related to? Are you asking for me to update my codepen to an anchor tag instead to see if it is the same?
|
|
||
Comment 8•4 years ago
|
||
Err, sorry, I had missed the codepen link, I was looking for an attachment on the bug :)
Yeah, the fact that a minimal transform on the drag handle makes it work as well makes me think this is almost certainly the same APZ bug we're looking into in the other bug.
So a workaround could be something like:
.drag-handle { transform: translate(1px, 1px); }
(And probably adjusting the position to compensate for that)
|
|
Reporter | |
Comment 9•4 years ago
|
||
Yeah makes sense. I couldn't find the other bug but it definitely looks like the same issue. We are going ahead with a workaround of adjusting the height of the iframe to 99.9999% instead of 100% as visually it looks the exact same (.013px difference) and seems to get it to behave as expected. I will follow the other bug thank you!
|
|
||
Comment 10•4 years ago
|
||
Confirmed that my patches for bug 1747409 also fix your codepen :)
Description
•