Bug 82769 – [chromium] Protect CSS filters code with #if ENABLE(CSS_FILTERS).

• Status: RESOLVED
• Resolution: WONTFIX
• Component: New Bugs

[Stephen White]

[chromium] Protect CSS filters code with #if ENABLE(CSS_FILTERS).

[Stephen White]

Created attachment 134863 [details]
Patch

[Dana Jansens]

We're going to be exposing these filters to Aura. Other than the change in GraphicsLayerChromium, can we unprotect them on aura?

Is this guarding important? I think this will be a core feature of the compositor.

[James Robinson]

Comment on attachment 134863 [details]
Patch

We set ENABLE(CSS_FILTERS) to true in chromium today, right?  Do we ever expect to set it to false?

I don't personally see much value in guarding chromium-specific code with ENABLE()s that we know are always going to be true.  For instance, we don't have any USE(SKIA) guards or ENABLE(WEBGL) guards since we don't support compiling without those options.  I generally think that's a good thing.

[James Robinson]

To be clear if we thought there was a reasonable chance that we'd have to turn css filters off at compile time then I'd be supportive of adding guards and adding bots to check that configuration (or it would just regress immediately).  However until that becomes a concrete reality having the guards is just unnecessary noise.

[Stephen White]

When I disabled them on the M18 branch, I wrote this CL in case we needed to disable them on M19, and thought I'd land it just in case we needed to do so in the future.  Not a big deal.

There might be a lighter-weight way of disabling them too (perhaps just removing the CSS parsing).

[James Robinson]

I see.  I think having runtimes guards is easier to maintain if we have that control.  The problem with ifdefs on branches is unless they're perfect at the branch point you need to do a buncha other stuff anyway, and without a bot to make sure that things still compile with the #ifdef set to the non-default option it's very likely to break.

[Stephen White]

NBD, I'll just close this.