CSS blur() filter wrongly renders when use in CSS transition
Reported by
khoinguy...@gmail.com,
Jul 29 2016
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36 Example URL: http://codepen.io/khoi/full/xOJbBq/ Steps to reproduce the problem: 1. Position an element so that its height or width exceeds that of the window. 2. Declare a CSS transition rule on the element. 3. Declare a CSS blur rule on the element when it is interacted (in this case "hover"). 4. Hover the element and see the blurring render. What is the expected behavior? The element should be rendered as if it exceeds the display. What went wrong? The blur() filter applies on the element as if the element stops at the display. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 52.0.2743.82 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0 This bug (?) does not occur on Firefox.
,
Jul 30 2016
This also appears on Chrome for Android.
,
Aug 1 2016
,
Aug 1 2016
I've come back to this again today. Seems like it also appears when being animated with `animation` CSS rule too.
,
Aug 1 2016
Unable to repro using requestAnimationFrame() and JS, not a paint issue. http://codepen.io/anon/pen/JKBxAO
,
Aug 2 2016
To clarify my above comment, this is definitely a bug in animation code since it's not reproducible with pure JS. I was able to repro the bug with --disable-threaded-animations so it's an issue with main thread animation code. We should investigate what the difference is between animations setting the value of filter and JS setting the value of filter.
,
Aug 2 2016
,
Aug 24 2016
alancutter@, the correct cmd switch is: --disable-threaded-animation (without 's), JFYI.
,
Sep 12 2016
,
Sep 12 2016
Looks like this is a painting/compositor issue. Can be reproduced with will-change: transform. https://jsfiddle.net/oys2jzh2/
,
Sep 12 2016
,
Mar 23 2017
bisect-builds says this was fixed by: https://chromium.googlesource.com/chromium/src/+log/4868d4131b01a3e3520fcb2d65d9c5a1058a606a..fba6c12e687130b2c3fe4d812d51e52592e701e1 most likely: https://chromium.googlesource.com/chromium/src/+/e947a35bcd6dce91dc4651680c48f8b996f7ea5e
,
Apr 5 2017
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by kojii@chromium.org
, Jul 30 2016Labels: -OS-Windows OS-All
Status: Untriaged (was: Unconfirmed)