Sorry, forgot to attach the screenshot, here it is.

Deleted: black.png 148 KB

	black.png 148 KB View Download

Curious - does -webkit-filter (not backdrop, that is) work for you?

Additional findings: when disabling experimental web platform features, the black square is not rendered, instead the feature has no effect. So the black is only rendered with experimental web platform features enabled.

#3 -
That makes sense, without the flag, backdrop-filter is not supported.

@phistuck: No, not on this machine that is. -webkit-filter does nothing at all, without the prefix I get the solid black. 

Another strange finding: when inspecting one of such black areas in developer tools and then using the color picker of the inspector to change the color, it suddenly works. If I then do any action on the page (i.e. scroll), it returns to solid black.

And I assume that -webkit-filter does not work regardless of the flag.

True, but I believe Safari needs it.

Chrome requires it as well.
It may look as if it accepts filter unprefixed, but it only truly works for SVG, and only with a url() value (or something like that, I forget the details).

I meant that filters are simply yielding black, regardless of whether the flag is enabled or not and regardless of whether you use a backdrop filter, or a normal filter.

"It may look as if it accepts filter unprefixed, but it only truly works for SVG, and only with a url() value (or something like that, I forget the details)."

This does not match my findings. If I start a browserstack session (Windows 10, Chrome latest (50)) and try any of the backdrop filter demos without prefix, it works fine, without SVG or URLs. This is what led me to believe it's a local issue.

"I meant that filters are simply yielding black, regardless of whether the flag is enabled or not and regardless of whether you use a backdrop filter, or a normal filter."

I get the black only when all of the following are true:
- flag enabled
- backdrop filter
- without prefix

Without the flag or with the prefix, there's simply no effect, but no black. Normal filters (foreground filters) work fine in any case (with a prefix).

>It may look as if it accepts filter unprefixed, but it only truly works for SVG, and only with a url() value (or something like that, I forget the details).
When I wrote "filter" there, I meant "filter" specifically, not "backdrop-filter".

Prefixed backdrop filters are not supported, regardless of the flag, so that makes sense.

So the issue happens only with backdrop filters (and only when they are applied, obviously, which requires the flag). Prefixed normal filters, regardless of the flag, work. Thank you for the clarification.

Yes, all of that is correct :)

Hello, this is your friendly bug triage sheriff!

Is this still a bug then? Assigning to Blink>CSS>Filters.

Those glCopyTexImage2D() errors look problematic. I wonder if ANGLE (+geofflang) or the legacy command buffer (+zmo) are incorrectly rejecting them? I don't have access to a Windows machine right now, but maybe one of you guys could take a look.

[8416:10952:0516/014141:ERROR:gles2_cmd_decoder.cc(11536)] : [.C
ommandBufferContext.Compositor-07659FD0]GL ERROR
:GL_INVALID_OPERATION : glCopyTexImage2D:

I think I ran into this and have a fix at https://codereview.chromium.org/2089753003/, at least it was verrrry similar.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a85bd24aa12d06f088ec083a01ceaf4ef54ead67

commit a85bd24aa12d06f088ec083a01ceaf4ef54ead67
Author: danakj <danakj@chromium.org>
Date: Wed Jun 22 22:25:49 2016

cc: Use the correct internal format for glCopyTexImage2D calls.

This uses the correct format for glCopyTexImage2D calls from the
default framebuffer (for the root renderpass). This function is used
for the implementation of backdrop filters.

Currently it uses GL_RGBA, but it is not valid to add a channel, so
if the framebuffer is only RGB, then we must use GL_RGB or it will fail.

This is demonstrated by the backdrop filter layout tests once they
use a cc::Display for doing GL drawing, instead of the current method
with a MailboxOutputSurface, which happens to provide an RGBA
framebuffer.

The layout tests are:
css3/filters/backdrop-filter-rendering.html
css3/filters/backdrop-filter-rendering-no-background.html

This also changes the ContextProvider used by cc pixel tests
to drop the alpha. With that, a number of pixel tests require
new baselines, as the background becomes black instead of
transparent, and some tests use background filters or leave some
pixels undrawn.

With the change to the pixel tests, but without the change in
GLRenderer, many cc pixel tests fail showing black for any
background filter, as exhibited by  bug 612238 , along with the
error "GL ERROR :GL_INVALID_OPERATION : glCopyTexImage2D:
incompatible format".

R=fsamuel@chromium.org, piman@chromium.org, sievers
BUG= 311404 ,  612238 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2089753003
Cr-Commit-Position: refs/heads/master@{#401438}

[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/android_webview/browser/aw_render_thread_context_provider.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/android_webview/browser/aw_render_thread_context_provider.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/android_webview/browser/parent_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/android_webview/browser/parent_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/blimp/client/feature/compositor/blimp_context_provider.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/blimp/client/feature/compositor/blimp_context_provider.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/blimp/client/feature/compositor/blimp_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/blimp/client/feature/compositor/blimp_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/output/gl_renderer.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/output/gl_renderer.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/output/gl_renderer_unittest.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/output/output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/output/output_surface_unittest.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/output/overlay_unittest.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/output/renderer_unittest.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/resources/resource_format.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/resources/resource_format.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/surfaces/surface_display_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/surfaces/surface_display_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/test/data/background_filter_blur_off_axis.png
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/test/data/background_filter_blur_outsets.png
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/test/data/background_filter_rotated_gl.png
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/test/data/force_anti_aliasing_off.png
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/test/fake_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/test/fake_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/test/pixel_test_delegating_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/test/pixel_test_delegating_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/test/pixel_test_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/test/pixel_test_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/test/test_in_process_context_provider.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/cc/trees/layer_tree_host_pixeltest_filters.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/components/display_compositor/buffer_queue.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/components/display_compositor/buffer_queue.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/components/mus/public/cpp/lib/output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/components/mus/public/cpp/output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/components/mus/surfaces/direct_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/components/mus/surfaces/direct_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/components/mus/surfaces/direct_output_surface_ozone.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/components/mus/surfaces/direct_output_surface_ozone.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/browser/compositor/gpu_browser_compositor_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/browser/compositor/gpu_browser_compositor_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/browser/compositor/gpu_surfaceless_browser_compositor_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/browser/compositor/gpu_surfaceless_browser_compositor_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/browser/compositor/offscreen_browser_compositor_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/browser/compositor/offscreen_browser_compositor_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/browser/compositor/reflector_impl_unittest.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/browser/compositor/software_browser_compositor_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/browser/compositor/software_browser_compositor_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/browser/renderer_host/compositor_impl_android.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/common/gpu/client/context_provider_command_buffer.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/common/gpu/client/context_provider_command_buffer.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/renderer/android/synchronous_compositor_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/renderer/android/synchronous_compositor_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/renderer/gpu/compositor_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/renderer/gpu/compositor_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/test/mailbox_output_surface.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/content/test/mailbox_output_surface.h
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/ui/compositor/test/in_process_context_factory.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/ui/compositor/test/in_process_context_provider.cc
[modify] https://crrev.com/a85bd24aa12d06f088ec083a01ceaf4ef54ead67/ui/compositor/test/in_process_context_provider.h

I'd love to hear if this gets fixed on Windows Canary. There's no url to test in the bug report.

http://omahaproxy.appspot.com/ says canary's branch_base_position is currently at 400850. Once that goes past 401438, I hope this is fixed.

Oh, http://codepen.io/joshuapekera/pen/waPVjN is a repro, I thought that was a screenshot.

This works on TOT for linux now, but it was also working before the above patch on linux (the framebuffer must come with alpha).

Canary 53.0.2777.0 is 401526 now. ferdy.christant@gmail.com, can you give it a try on your machine?

@danakj: works for me on Canary (Version 53.0.2778.0 canary (64-bit), Windows 10. Great job :)

Thank you for providing more feedback. Adding requester "danakj@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for confirming!

Sounds like this has been broken since 49, but requesting merge to beta to see if we can get the fix out soonish.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

I think way too much has changed since 52, this patch is not really mergable. So we'll have to wait for 53 sorry.

Thanks very much for the fix! It's a bit worrying that we didn't have test coverage. Am I correct that this is not because we didn't have tests, but because we weren't testing what we ship? And this is fixed now?

WRT merging, this feature is still behind a runtime flag, so I think it's fine to wait for 53.

The unit tests that I rebaselined fail without the change now.

We were not testing what we ship, that's true, so we had an RGBA backbuffer in layout tests, but some (most?) platforms provide only an RGB backbuffer. Now we're at least testing what we would ship for a given platform/device. And the cc unit tests no longer have an alpha channel in the backbuffer either via osmesa.

 Issue 593424  has been merged into this issue.

 Issue 570040  has been merged into this issue.