CSSGrammer.y should not allow missing closing bracket when it parses querySelector's selector text.

CSSGrammer.y should not allow missing closing bracket when it parses querySelector's selector text.

Spec: http://www.w3.org/TR/selectors-api/#processing-selectors
If result is invalid ([SELECT], section 12), raise a SYNTAX_ERR exception ([DOM-LEVEL-3-CORE], section 1.4) and
abort this algorithm.

BUG=380033
TEST=fast/css/parsing-unexpected-eof.html

[tasak, 2014-06-09 09:06:14]

Would you review this CL?

[dglazkov, 2014-06-09 16:43:27]

On 2014/06/09 at 09:06:14, tasak wrote:
> Would you review this CL?

LGTM.

"CSSGrammar.y" is misspelled in the title :)

[rune, 2014-06-09 20:37:24]

Unless there are real world incompatibilities here, I don't think this is the
right thing to do. I have added Tab.

The CSS3 Syntax spec has end-of-simple-block handling as part of the
tokenization handling this at the block level:
http://www.w3.org/TR/2014/CR-css-syntax-3-20140220/#consume-a-simple-block0 that
would generate a valid simple-block token out of this:

  [attr="x"

I found this thread (which I havent' read in detail yet):

http://lists.w3.org/Archives/Public/www-style/2012Oct/0832.html

and in particular this post:

http://lists.w3.org/Archives/Public/www-style/2012Oct/0838.html

which indicates we shouldn't tokenize differently in Selectors API, including
EOF handling.

[Tab Atkins, 2014-06-09 22:09:53]

On 2014/06/09 20:37:24, rune wrote:
> Unless there are real world incompatibilities here, I don't think this is the
> right thing to do. I have added Tab.
> 
> The CSS3 Syntax spec has end-of-simple-block handling as part of the
> tokenization handling this at the block level:
> http://www.w3.org/TR/2014/CR-css-syntax-3-20140220/#consume-a-simple-block0
that
> would generate a valid simple-block token out of this:
> 
>   [attr="x"
> 
> I found this thread (which I havent' read in detail yet):
> 
> http://lists.w3.org/Archives/Public/www-style/2012Oct/0832.html
> 
> and in particular this post:
> 
> http://lists.w3.org/Archives/Public/www-style/2012Oct/0838.html
> 
> which indicates we shouldn't tokenize differently in Selectors API, including
> EOF handling.

Yes, "[attr='x'" should be valid - the [] block gets auto-closed by the CSS
parser, per spec, so it's undetectable whether the "]" is present or not.

Sorry that Selector parsing isn't well-defined yet.  I plan to fix this soon,
rebasing it over the Syntax spec rather than the 2.1 grammar.

[rune, 2014-06-09 22:18:11]

not lgtm

[tasak, 2014-06-10 00:47:42]

Thank you for reviewing.

On 2014/06/09 22:09:53, Tab Atkins wrote:
> On 2014/06/09 20:37:24, rune wrote:
> > Unless there are real world incompatibilities here, I don't think this is
the
> > right thing to do. I have added Tab.
> > 
> > The CSS3 Syntax spec has end-of-simple-block handling as part of the
> > tokenization handling this at the block level:
> > http://www.w3.org/TR/2014/CR-css-syntax-3-20140220/#consume-a-simple-block0
> that
> > would generate a valid simple-block token out of this:
> > 
> >   [attr="x"
> > 
> > I found this thread (which I havent' read in detail yet):
> > 
> > http://lists.w3.org/Archives/Public/www-style/2012Oct/0832.html
> > 
> > and in particular this post:
> > 
> > http://lists.w3.org/Archives/Public/www-style/2012Oct/0838.html
> > 
> > which indicates we shouldn't tokenize differently in Selectors API,
including
> > EOF handling.
> 
> Yes, "[attr='x'" should be valid - the [] block gets auto-closed by the CSS
> parser, per spec, so it's undetectable whether the "]" is present or not.
> 
> Sorry that Selector parsing isn't well-defined yet.  I plan to fix this soon,
> rebasing it over the Syntax spec rather than the 2.1 grammar.

I see.
I should not fix crbug.com/380033 because the bug depends on selector spec bug.

I will close this CL and comment on crbug.com/380033.