A dialog element displayed with showModal ignores CSS transitions.
Reported by
mysteryt...@gmail.com,
Mar 31 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Steps to reproduce the problem: Click the `Show Modal` button. What is the expected behavior? The dialog should slide into view, as happens when you click the `Show` button. What went wrong? The dialog appears on screen (and disappears off screen, when you click 'Go away') rather than sliding into view (and sliding out of view). It works fine if you do it programmatically with `animate()`. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 58.0.3029.41 (Official Build) beta (64-bit) Channel: beta OS Version: 10.0 Flash Version: Shockwave Flash 24.0 r0 I can't see anything in the spec that says this shoudn't work. Edge/Firefox don't support dialogs so I can't test to see if I'm being dumb.
,
Apr 3 2017
Able to reproduce this issue on Mac 10.12.3, Win-10 and Ubuntu 14.04 using chrome reported version #58.0.3029.41 and latest canary #59.0.3060.0. This is a non-regression issue as it is observed from M40 old builds. Note: From M35 and older builds, chrome doesn't support dialogs. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Apr 3 2017
Do we have the way to detect via DOM that which method(show or showModal) run?
,
Apr 3 2017
Rerouting to HTML>Dialog.
,
Apr 13 2017
,
Apr 14 2017
I spent an afternoon digging into the codebase. There's a lot I don't understanding but in `HTMLDialogElement::showModal()` the dialog node is detached from the tree via `document().addToTopLayer(this)`, _then_ the open attribute is set, and then sometime later, perhaps during the call to `forceLayoutForCentering()`, the node is reattached to the tree. So I'm guessing setting the open attribute while detached causes the transition to be elided. And maybe it can be fixed on display by setting the open attribute after the call `forceLayoutForCentering()`. (FWIW Manually removing the `open` attribute from js immediately after the call to `showModal()` causes the transition to fire. I don't know how diagnostic that is.) Close doesn't even seem to force a layout change and refrain from clearing the `open` attribute until it's happened. But maybe it's all a bit more complicated than that. One more question: Should the call to `inertSubtreesChanged(document())` happen before the `document().addToTopLayer(this)`? Because addToTopLayer will utilise the AX tree. If this remains open long enough, I will have a go at checking out Chrome and building it. It depends on how time.
,
Apr 16 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 23 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ligim...@chromium.org
, Mar 31 2017Labels: Needs-Bisect Needs-Triage-M58