Iframe contents inside a css animated (transform: scale, opacity, visibility) absolutely positioned element are not initially rendered
Reported by
livechap...@gmail.com,
Nov 7 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2911.0 Safari/537.36 Steps to reproduce the problem: Here is a live example: https://www.chaport.com/ 1. after page has finished loading, click a chat button in left bottom corner 2. it will expand a div with white background and iframe in it (iframe contents are not rendered) 3. open dev tools 3a. removing and adding back position: absolute on div.chaport-window element makes its content visible 3b. find an element "#chat > div.chaport-inner-header > div.chaport-close" inside an iframe, and click on it (it will close the widget), click on chat button again (as in step 1), it will open a widget again, but this time iframe contents will be rendered What is the expected behavior? What went wrong? iframe contents should be visible on step 2 Did this work before? Yes 54.0.2840.87 (latest released chrome) Chrome version: 56.0.2911.0 Channel: canary OS Version: 10.0 Flash Version: This issue doesn't occur when widget is initially expanded (it persists its state through page reloads, you might have to close it before refreshing the page in order to reproduce the problem again) The widget is shown/hidden using css transformation that looks like this: transition: visibility 0s linear 0.2s,opacity linear 0.2s,transform ease-in-out 0.2s; removing "transform: scale" from transitions makes iframe contents appear (it then disappears for a couple seconds and appears again for no apparent reason)
,
Nov 17 2016
Issue is still reproduced on Mac OS 10.11.6 using latest Chrome canary M56 #56.0.2922.0 . @skyostil -- Could you please look into this. Thanks!
,
Nov 28 2016
skyostil@, Can we get an update on this please
,
Dec 8 2016
Sorry for the delay -- and thanks for the very useful reproduction case! This seems to be a bug in our intersection observer implementation. What happens is this: 1. Chat frame is moved onscreen with a size of 0x0 => intersection observation with index = 1, ratio = 0 is queued. 2. Chat frame is resized to a non-zero size => no observation is queued because we were already at index = 1. According to the spec, ratio should be 1 in step 1. I'll put together a patch.
,
Dec 8 2016
,
Dec 9 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8296d3b0e6a755dabf607b78a259f86803699d88 commit 8296d3b0e6a755dabf607b78a259f86803699d88 Author: skyostil <skyostil@chromium.org> Date: Fri Dec 09 20:15:46 2016 IntersectionObserver: compute correct intersection ratio for 0x0 elements When a 0x0 element is in view, its intersection ratio is defined[1] to be 1. BUG= 662826 [1] https://wicg.github.io/IntersectionObserver/#update-intersection-observations-algo Review-Url: https://codereview.chromium.org/2556243003 Cr-Commit-Position: refs/heads/master@{#437617} [add] https://crrev.com/8296d3b0e6a755dabf607b78a259f86803699d88/third_party/WebKit/LayoutTests/intersection-observer/zero-area-element-hidden.html [add] https://crrev.com/8296d3b0e6a755dabf607b78a259f86803699d88/third_party/WebKit/LayoutTests/intersection-observer/zero-area-element-visible.html [modify] https://crrev.com/8296d3b0e6a755dabf607b78a259f86803699d88/third_party/WebKit/Source/core/dom/IntersectionObservation.cpp
,
Dec 12 2016
,
Dec 12 2016
Your change meets the bar and is auto-approved for M56 (branch: 2924)
,
Dec 13 2016
Thanks for the fix, we will verify in today's canary. If looks good please merge to M56.
,
Dec 14 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/347055486e3cd64661a5c7f510adffef8886f87e commit 347055486e3cd64661a5c7f510adffef8886f87e Author: skyostil <skyostil@chromium.org> Date: Wed Dec 14 17:04:29 2016 IntersectionObserver: compute correct intersection ratio for 0x0 elements When a 0x0 element is in view, its intersection ratio is defined[1] to be 1. BUG= 662826 TBR=szager@chromium.org NOTRY=true NOPRESUBMIT=true [1] https://wicg.github.io/IntersectionObserver/#update-intersection-observations-algo Review-Url: https://codereview.chromium.org/2556243003 Cr-Commit-Position: refs/heads/master@{#437617} (cherry picked from commit 8296d3b0e6a755dabf607b78a259f86803699d88) Review-Url: https://codereview.chromium.org/2566943004 Cr-Commit-Position: refs/branch-heads/2924@{#491} Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059} [add] https://crrev.com/347055486e3cd64661a5c7f510adffef8886f87e/third_party/WebKit/LayoutTests/intersection-observer/zero-area-element-hidden.html [add] https://crrev.com/347055486e3cd64661a5c7f510adffef8886f87e/third_party/WebKit/LayoutTests/intersection-observer/zero-area-element-visible.html [modify] https://crrev.com/347055486e3cd64661a5c7f510adffef8886f87e/third_party/WebKit/Source/core/dom/IntersectionObservation.cpp
,
Dec 16 2016
,
Jan 4 2017
Verified this issue on Windows-10, Mac OS 10.12.2 and Ubuntu 14.04 using chrome latest M56 #56.0.2924.51 by following steps mentioned in the original comment. Able to see the iframe contents properly Adding TE-Verified label. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by hdodda@chromium.org
, Nov 8 2016Labels: hasbisect-per-revision M-56 OS-Linux OS-Mac
Owner: skyos...@chromium.org
Status: Assigned (was: Unconfirmed)