686 bytes, text/html
853 bytes, text/html
1.73 KB, text/html
59 bytes, text/x-review-board-request
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20141125180439 Steps to reproduce: Our site is designed to become grayscale under certain circumstances. We apply an SVG filter similar to this one: http://stackoverflow.com/a/12173285, http://jsfiddle.net/xDJzU/7/ For some reason, this doesn't work with the particular combination of elements we have on our page. 1) Go to http://beta.adventurecow.com/stories/1/the-brownsville-detective-service/p/start?pid=None 2) Apply the filter CSS property to the body element: filter: url("data:image/svg+xml;utf8,<svg xmlns=\'http://www.w3.org/2000/svg\'><filter id=\'grayscale\'><feColorMatrix type=\'matrix\' values=\'0.3333 0.3333 0.3333 0 0 0.3333 0.3333 0.3333 0 0 0.3333 0.3333 0.3333 0 0 0 0 0 1 0\'/></filter></svg>#grayscale"); -- This has worked on other pages (on this one, for instance); so not sure what we're adding to the DOM that causes the break. Thanks! Actual results: Page disappears. Expected results: Page should become grayscale.
Please add a small as possible testcase which demonstrates the issue (without manually changing anything) to the issue. The filter seems to work for me, though I suspect adding it to the body of the webpage is not a good idea.
I can confirm the issue on Mac nightly, for what it's worth...
Keywords: qawanted, testcase-wanted
Hi Robert - the filter was working on the body of that beta.adventurecow.com page? Well, that's confusing. Maybe a different version. This was a difficult issue to debug, because when I start with a page from scratch the filter works just fine. I'm not sure at what point the filter causes a problem, but... I did do an experiment that might help. If you set the height of the html and body elements in the test case to 100%, the filter works fine. I suppose perhaps the filter causes the rendering engine to redraw the body box, clipping everything outside of it? I have no idea, but hopefully that makes the cause of this behavior apparent to someone with more knowledge than I...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: CSS grayscale filter (using url property) causes filtered element to disappear, in certain instances → CSS grayscale filter (using url property) causes filtered element to disappear, in certain instances(position: fixed/absolute)
Robert, can you look into this? If not, do you know who can?
I had a look this weekend. It doesn't seem like it's getting to the filter painting code which suggests that something might be going wrong constructing layers. I will keep looking but you might want someone who has more time to look into this such as mstange.
Reproduced on Windows 7 64-bit, Ubuntu 14.04 64-bit and Mac OS X 10.9.5 using latest Firefox Nightly, build ID: 20150318055750.
Keywords: qawanted, testcase-wanted → testcase
OS: Windows 7 → All
QA Contact: cornel.ionce
Hardware: x86_64 → All
Version: 34 Branch → Trunk
For what it’s worth what I have found is that any absolutely or fixed positioned element inside an element that has any CSS filter applied disappears. I have tested in the latest Firefox on both OS X and Linux. Here is a simple fiddle to demonstrate the issue: http://jsbin.com/topaqoqebe/1/edit?html,css,output
Have the same issue. A workaround is to give the filter element a stacking context in any way. According to the spec, filter is supposed to do that by itself, so I think that's the crux of the problem.
I'm sorry. There's obviously more to this. Filter does indeed seem to create a stacking context. Not much seems to make a fixed child appear, but making the filtered element relative at least renders absolute children.
If element has filter initially, its children will use this element as containing block. If filter has dynamically added to element, then it will hide overflowing children. By children I mean an either absolutely or fixed positioned element inside an element with filter. http://jsfiddle.net/SerGen/Ld3hqak2/ Firefox DE 41.0a2 (12.07.2015)
I can add some more to this. http://mon.github.io/firefoxInvert/ Correct behaviour would have the text at the bottom of the window, and removing the filter (NOT through the devtools, a refresh is required) displays it as such. With the filter applied, the text is located above the margin - it doesn't disappear, it's just rendered in the wrong spot.
Duplicate of bug 1226095?
Some of the comments in this bug are, but it's not clear the the original reported issue is.
You need to log in before you can comment on or make changes to this bug.