Add an about:flags entry for CSS Shaders.

Add an about:flags entry for CSS Shaders.

BUG=141433
TEST=Check that CSS Shaders can be enabled and disabled in about:flags

[maxvujovic, 2012-08-09 23:06:08]

Hi guys,

Does this look ok?

Thanks,
Max

[Ken Russell (switch to Gerrit), 2012-08-10 20:54:09]

https://chromiumcodereview.appspot.com/10831216/diff/1/chrome/app/generated_r...
File chrome/app/generated_resources.grd (right):

https://chromiumcodereview.appspot.com/10831216/diff/1/chrome/app/generated_r...
chrome/app/generated_resources.grd:5835: +        Enable CSS Shaders.
How about a more detailed description of the functionality? See
IDS_FLAGS_STACKED_TAB_STRIP_DESCRIPTION,
IDS_FLAGS_INSTANT_AUTOCOMPLETE_IMMEDIATELY_DESCRIPTION, etc. for examples.

[maxvujovic, 2012-08-10 20:54:37]

Per Alok's suggestion, adding senorblanco to the reviewers list.

[maxvujovic, 2012-08-11 02:42:24]

Thanks for the review!

https://chromiumcodereview.appspot.com/10831216/diff/1/chrome/app/generated_r...
File chrome/app/generated_resources.grd (right):

https://chromiumcodereview.appspot.com/10831216/diff/1/chrome/app/generated_r...
chrome/app/generated_resources.grd:5835: +        Enable CSS Shaders.
On 2012/08/10 20:54:09, kbr wrote:
> How about a more detailed description of the functionality? See
> IDS_FLAGS_STACKED_TAB_STRIP_DESCRIPTION,
> IDS_FLAGS_INSTANT_AUTOCOMPLETE_IMMEDIATELY_DESCRIPTION, etc. for examples.

I've changed the description to: 
"Enable filter effects on DOM elements using custom GLSL shaders. More info at
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feCustomElement."

What do you think?

[Ken Russell (switch to Gerrit), 2012-08-11 02:47:21]

Thanks, that's better. LGTM

[commit-bot: I haz the power, 2012-08-11 03:17:58]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/maxvujovic@gmail.com/10831216/5001

[commit-bot: I haz the power, 2012-08-11 03:18:00]

Presubmit check for 10831216-5001 failed and returned exit status 1.


Running presubmit commit checks ...

** Presubmit Warnings **
maxvujovic@gmail.com is not in AUTHORS file. If you are a new contributor,
please visit
http://www.chromium.org/developers/contributing-code and read the "Legal"
section
If you are a chromite, verify the contributor signed the CLA.

** Presubmit ERRORS **
Missing LGTM from an OWNER for files in these directories:
    chrome

[Stephen White, 2012-08-13 14:30:41]

Unless the known security issues* regarding this feature have been resolved, I
would really like to see an infobar warning users that they're running with an
insecure feature before it's surfaced in about:flags.

* http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security

[maxvujovic, 2012-08-13 18:34:52]

On 2012/08/13 14:30:41, Stephen White wrote:
> Unless the known security issues* regarding this feature have been resolved, I
> would really like to see an infobar warning users that they're running with an
> insecure feature before it's surfaced in about:flags.
> 
> * http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security

Thanks for feedback, Stephen.

We're a few WebKit patches away [1-3] from implementing the proposed security
model and removing direct texture access [1]. I think we can hold off on adding
the about:flag until those land in a couple of weeks. Then, we won't need an
infobar warning.

Of course, in the long run, we'd like to see direct texture access in CSS
Shaders, but that's a greater undertaking that's going to take some more
research [4]. The CSS Shaders spec is designed with this in mind, though.

[1] https://bugs.webkit.org/show_bug.cgi?id=93871
[2] https://bugs.webkit.org/show_bug.cgi?id=93870
[3] https://bugs.webkit.org/show_bug.cgi?id=93869

[4]
http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security#Method_H:_Tainting_sh...

[maxvujovic, 2012-09-12 20:20:37]

On 2012/08/13 18:34:52, mvujovic wrote:
> On 2012/08/13 14:30:41, Stephen White wrote:
> > Unless the known security issues* regarding this feature have been resolved,
I
> > would really like to see an infobar warning users that they're running with
an
> > insecure feature before it's surfaced in about:flags.
> > 
> > * http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security
> 
> Thanks for feedback, Stephen.
> 
> We're a few WebKit patches away [1-3] from implementing the proposed security
> model and removing direct texture access [1]. I think we can hold off on
adding
> the about:flag until those land in a couple of weeks. Then, we won't need an
> infobar warning.
> 
> Of course, in the long run, we'd like to see direct texture access in CSS
> Shaders, but that's a greater undertaking that's going to take some more
> research [4]. The CSS Shaders spec is designed with this in mind, though.
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=93871
> [2] https://bugs.webkit.org/show_bug.cgi?id=93870
> [3] https://bugs.webkit.org/show_bug.cgi?id=93869
> 
> [4]
>
http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security#Method_H:_Tainting_sh...

We've updated the CSS Shaders security model in WebKit, so I think this is ready
to land. (See WebKit r128334 http://trac.webkit.org/changeset/128334).

Stephen- Does that sound ok?

[Stephen White, 2012-09-13 13:49:56]

On 2012/09/12 20:20:37, mvujovic wrote:
> On 2012/08/13 18:34:52, mvujovic wrote:
> > On 2012/08/13 14:30:41, Stephen White wrote:
> > > Unless the known security issues* regarding this feature have been
resolved,
> I
> > > would really like to see an infobar warning users that they're running
with
> an
> > > insecure feature before it's surfaced in about:flags.
> > > 
> > > * http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security
> > 
> > Thanks for feedback, Stephen.
> > 
> > We're a few WebKit patches away [1-3] from implementing the proposed
security
> > model and removing direct texture access [1]. I think we can hold off on
> adding
> > the about:flag until those land in a couple of weeks. Then, we won't need an
> > infobar warning.
> > 
> > Of course, in the long run, we'd like to see direct texture access in CSS
> > Shaders, but that's a greater undertaking that's going to take some more
> > research [4]. The CSS Shaders spec is designed with this in mind, though.
> > 
> > [1] https://bugs.webkit.org/show_bug.cgi?id=93871
> > [2] https://bugs.webkit.org/show_bug.cgi?id=93870
> > [3] https://bugs.webkit.org/show_bug.cgi?id=93869
> > 
> > [4]
> >
>
http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security#Method_H:_Tainting_sh...
> 
> We've updated the CSS Shaders security model in WebKit, so I think this is
ready
> to land. (See WebKit r128334 http://trac.webkit.org/changeset/128334).
> 
> Stephen- Does that sound ok?

Sounds good.  LGTM.

[sky, 2012-09-13 17:41:01]

LGTM

[mal, 2012-09-13 17:42:49]

http://codereview.chromium.org/10831216/diff/13001/AUTHORS
File AUTHORS (right):

http://codereview.chromium.org/10831216/diff/13001/AUTHORS#newcode201
AUTHORS:201: Max Vujovic <maxvujovic@gmail.com>
Note that maxvujovic@gmail.com does not appear on the CLA signers list
(mvujovic@adobe.com is authorized by Adobe). 

Is there a reason you can't use the @adobe.com address?

[maxvujovic, 2012-09-13 17:52:18]

On 2012/09/13 17:42:49, mal wrote:
> http://codereview.chromium.org/10831216/diff/13001/AUTHORS
> File AUTHORS (right):
> 
> http://codereview.chromium.org/10831216/diff/13001/AUTHORS#newcode201
> AUTHORS:201: Max Vujovic <mailto:maxvujovic@gmail.com>
> Note that mailto:maxvujovic@gmail.com does not appear on the CLA signers list
> (mailto:mvujovic@adobe.com is authorized by Adobe). 
> 
> Is there a reason you can't use the @adobe.com address?

I'll try to hook up my @adobe.com address to my gmail account and reupload the
patch under that alias.

[commit-bot: I haz the power, 2012-09-13 18:55:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/maxvujovic@gmail.com/10831216/14002

[commit-bot: I haz the power, 2012-09-13 18:55:09]

Presubmit check for 10831216-14002 failed and returned exit status 1.


Running presubmit commit checks ...

** Presubmit Warnings **
maxvujovic@gmail.com is not in AUTHORS file. If you are a new contributor,
please visit
http://www.chromium.org/developers/contributing-code and read the "Legal"
section
If you are a chromite, verify the contributor signed the CLA.

Presubmit checks took 1.0s to calculate.

[Max Vujovic (mvujovic), 2012-09-13 20:07:14]

On 2012/09/13 17:52:18, maxvujovic wrote:
> On 2012/09/13 17:42:49, mal wrote:
> > http://codereview.chromium.org/10831216/diff/13001/AUTHORS
> > File AUTHORS (right):
> > 
> > http://codereview.chromium.org/10831216/diff/13001/AUTHORS#newcode201
> > AUTHORS:201: Max Vujovic <mailto:maxvujovic@gmail.com>
> > Note that mailto:maxvujovic@gmail.com does not appear on the CLA signers
list
> > (mailto:mvujovic@adobe.com is authorized by Adobe). 
> > 
> > Is there a reason you can't use the @adobe.com address?
> 
> I'll try to hook up my @adobe.com address to my gmail account and reupload the
> patch under that alias.

I had to create another issue with my @adobe.com email address:
https://codereview.chromium.org/10913254

Long story short, I wasn't able to make the @adobe account the primary or
migrate the issue when I linked my accounts.

I think just Sky needs to LGTM that issue again. Sorry!