forked from mirrors/gecko-dev
d83da99f63
As with the previous patch in this series, we need to pay particular attention to how we handle display:table content when detecting animations on a element. Please see the extended description in that patch for an explanation of different frame types involved. As with transforms, our handling of opacity is also inconsistent. In particular, we fail to return true from nsIFrame::HasOpacityInternal for display:table content with opacity animations applied due to the conflicting requirements for a primary frame and having opacity animations (which are stored on the style frame). Unlike transforms, however, we do not inherit the opacity to the table wrapper. Instead we leave it on the inner table frame. As a result, we should not check for a primary frame, but instead we should check for the style frame for the primary frame. This patch adjusts this handling to check instead for the appropriate style frame as opposed to requiring a primary frame. It includes a reftest that fails without the code changes in this patch. Differential Revision: https://phabricator.services.mozilla.com/D21884 --HG-- extra : moz-landing-system : lando
25 lines
464 B
HTML
25 lines
464 B
HTML
<!DOCTYPE html>
|
|
<title>
|
|
Opacity animation on display:table element creates a stacking context even if it
|
|
has only 100% opacity in its keyframes
|
|
</title>
|
|
<style>
|
|
span {
|
|
height: 100px;
|
|
width: 100px;
|
|
position: fixed;
|
|
background: green;
|
|
top: 50px;
|
|
}
|
|
@keyframes Opaque {
|
|
from, to { opacity: 1; }
|
|
}
|
|
#test {
|
|
display: table;
|
|
width: 100px; height: 100px;
|
|
background: blue;
|
|
animation: Opaque 100s infinite;
|
|
}
|
|
</style>
|
|
<span></span>
|
|
<div id="test"></div>
|