537143 - support CSS transitions on and inside 'display:none' elements

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We should support CSS transitions on and inside 'display:none' elements, which can have their computed style queried or can be unhidden in the future.

See the thread:
http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b9982ceccf864478/fdf61cb2fdc54cd5
("CSS transitions on and inside 'display:none'")

Comment 3

[Ben Bucksch (:BenB)]

Please see bug 683696. The event not firing can really break stuff.

---

Note for searching:
This also applies to XUL hidden="true", which is essentially the same CSS "display:none".

---

I thought the following would work despite this bug, but it doesn't either:

#my[show=closed] {
  display: none;
  height: 0;
}
#my[show=opening] {
  height: 60px;
  -moz-transition: height 0.5s ease-in;
  overflow: hidden;
}

myEl.setAttribute("show", "opening");

I would have expected this to work despite this bug, because at the moment when I set "opening", the display: none is gone, and height should animate from 0 to 60.

But it doesn't. Firefox falls right over the fact that display:none applies. In other words, in the current implementation, the display:none drops *after* the animation starts.

Workaround is to add just another step:
#my[show=closed] {
  display: none;
}
#my[show=opening-start] {
  height: 0;
}
#my[show=opening] {...}

myEl.setAttribute("show", "opening-start");
myEl.setAttribute("show", "opening");

And now I feel silly.

But that STILL doesn't work. When I do

myEl.setAttribute("show", "opening-start");
setTimeout(function() { myEl.setAttribute("show", "opening"); }, 0);

it works. And now I feel "urgs".

Comment 4

[Ben Bucksch (:BenB)]

> Please see bug 683696.

Nevermind, dbaron said it's not related, our comments crossed.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I added some automated tests for this in bug 625289, marked as failing, in https://hg.mozilla.org/mozilla-central/rev/51037224ba03 .

Note that supporting transitions *on* display:none elements should be straightforward; it involves adding calls to RestyleManager::TryStartingTransition from ElementRestyler::RestyleUndisplayedChildren.

But supporting transitions *inside* display:none elements is substantially harder; it would involve figuring out how to decide when to compute style for entire display:none subtrees because they might have transitions in them.

I'm not sure that we should try to fix the first without also having a fix for the second.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

I don't think we want this. We don't want to have to do rendering work inside display: none subtrees.