background-attachement:fixed and filter blur issue
Reported by
rol...@nextendweb.com,
Nov 20 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Example URL: https://smartslider3.com/bugs/firefox/blurfixed/test.html Steps to reproduce the problem: 1. Open https://smartslider3.com/bugs/firefox/blurfixed/test.html 2. Resize your browser height to smaller than you screen 3. Scroll into the page 4. Resize your browser height to bigger 5. The background is not updated and the area is white below the image, if you scroll, it renders again fine. What is the expected behavior? It should render the image on browser resize What went wrong? Chrome does not update the image on resize Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? N/A Chrome version: 62.0.3202.94 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Also, I'm not sure if it is a bug or not, but I think the filter: blur() should be applied on the div instead of the final rendered image. In this fixed context this creates a box shadow inset effect on the image part which visible on the screen. I think filter:blur() should create that box shadow effect on the whole div and when you scroll lower, that top box shadow should go out of the screen.
,
Nov 21 2017
Able to reproduce this issue on Mac 10.12.6, Win-10 and Ubuntu 14.04 using chrome reported version #62.0.3202.94 and chrome version #64.0.3273.0. This is a non-regression issue as it is observed from M50 old builds. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Nov 28 2017
Appears to be a background invalidation issue. Feel free to un-assign - I just want some eyes on this to guess at the cause.
,
Dec 4 2017
There are two issues: 1. fixed-attachment background invalidation on window resize. The invalidation is missing even if there is no blur effect. We should either paint fixed-attachment background in full object size instead of in window size or invalidate the object when window resizes. 2. The behavior of filter effect on fixed-attachment background is questionable. (@trchen any idea?)
,
Dec 4 2017
filters should apply to fixed-attachment backgrounds. The painting area of fixed-attachment backgrounds are not different from other types of backgrounds. They just position their image tiles in a special way. It is weird that we correctly over-paint other types of backgrounds in the presence of filters but not for fixed-attachment. I suspect there may be some (incorrect) optimization that limited image tile generation to the viewport. As for invalidation on window resize, actually for many cases an invalidation is not needed. Backgrounds by default have background-size:auto; background-origin:0% 0%; background-repeat:repeat;, thus insensitive to position area size.
,
Dec 4 2017
> As for invalidation on window resize, actually for many cases an invalidation is not needed. Backgrounds by default have background-size:auto; background-origin:0% 0%; background-repeat:repeat;, thus insensitive to position area size. Do you mean the test case (which has default background size, origin and repeat) doesn't need invalidation? Are we painting it wrong by just painting the background inside of the viewport?
,
Dec 4 2017
Yes, I think it's getting clipped inadvertently.
,
Dec 4 2017
This is a painting issue: not painting the background in full size is equivalent to applying a clip in wrong paint property order, causing the filter is applied on wrong source. The clip or clip-equivalence also makes a fake requirement of paint invalidation on window resize which won't exist if we paint the background in full size.
,
Dec 12 2017
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by rol...@nextendweb.com
, Nov 20 2017