Adjust error-handling for invalid filter primitive references

Adjust error-handling for invalid filter primitive references

When a filter primitive has an 'in' (or, where applicable, 'in2') attribute
that references a non-existent result, treat that reference as having the
default value (==no value) instead of producing an error.
This aligns with Presto and IE.

BUG=411833
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=181733

[fs, 2014-09-09 16:31:47]

fs@opera.com changed reviewers:
+ fmalita@chromium.org, pdr@chromium.org, senorblanco@chromium.org

[Stephen White, 2014-09-10 12:39:42]

Code looks fine, but I'm wondering how to interpret the spec on this. The only
reference I could find was that "Forward references to results are an error."
Technically, this isn't a forward reference, but it would be somewhat hard to
distinguish them (referencing a non-existent node vs. one which hadn't been
parsed yet). Thoughts?

[fs, 2014-09-10 14:01:11]

On 2014/09/10 12:39:42, Stephen White wrote:
> Code looks fine, but I'm wondering how to interpret the spec on this. The only
> reference I could find was that "Forward references to results are an error."
> Technically, this isn't a forward reference, but it would be somewhat hard to
> distinguish them (referencing a non-existent node vs. one which hadn't been
> parsed yet). Thoughts?

The 1.1 spec did indeed state that it's an error, but no browser implement
strict 1.1 error semantics/handling anyway. The current ED of Filter Effects [1]
however say:

"Forward references to results are not allowed, and will be treated as if no
result was specified."

and "no result" would be the part covered by:

"If no value is provided ..."

in the preceding paragraph.

[1] http://dev.w3.org/fxtf/filters/#element-attrdef-in

[Stephen White, 2014-09-10 14:09:19]

On 2014/09/10 14:01:11, fs wrote:
> On 2014/09/10 12:39:42, Stephen White wrote:
> > Code looks fine, but I'm wondering how to interpret the spec on this. The
only
> > reference I could find was that "Forward references to results are an
error."
> > Technically, this isn't a forward reference, but it would be somewhat hard
to
> > distinguish them (referencing a non-existent node vs. one which hadn't been
> > parsed yet). Thoughts?
> 
> The 1.1 spec did indeed state that it's an error, but no browser implement
> strict 1.1 error semantics/handling anyway. The current ED of Filter Effects
[1]
> however say:
> 
> "Forward references to results are not allowed, and will be treated as if no
> result was specified."
> 
> and "no result" would be the part covered by:
> 
> "If no value is provided ..."
> 
> in the preceding paragraph.
> 
> [1] http://dev.w3.org/fxtf/filters/#element-attrdef-in

I've always thought the newer Filter Effects spec applied only to CSS Filter
Effects, not SVG. But perhaps I'm wrong about that.

In any case, I think we should at least align the corner cases in favour of the
newer spec. So LGTM.

[fs, 2014-09-10 14:21:27]

On 2014/09/10 14:09:19, Stephen White wrote:
> On 2014/09/10 14:01:11, fs wrote:
> > On 2014/09/10 12:39:42, Stephen White wrote:
...
> I've always thought the newer Filter Effects spec applied only to CSS Filter
> Effects, not SVG. But perhaps I'm wrong about that.

SVG2 references Filter Effects (https://svgwg.org/svg2-draft/filters.html), and
I believe this was one of the earlier "break-outs" from the SVG spec.
(Supposedly to make use outside of the SVG-spec easier.)

[fs, 2014-09-10 14:21:35]

The CQ bit was checked by fs@opera.com

[commit-bot: I haz the power, 2014-09-10 14:21:58]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/fs@opera.com/558693002/1

[commit-bot: I haz the power, 2014-09-10 14:25:29]

Committed patchset #1 (id:1) as 181733