.hasClass(".name") silently dies

[dmethvin]

If you erroneously use $().hasClass() with a leading dot on the class name, jQuery silently stops executing code in FF3.

The actual problem seems to be in jQuery.filter, which matches the leading ".." in the selector it's given and then tries to look that up in jQuery.expr and gets undefined, but still tries to call it as a function.

This clearly is a user input error case so I wouldn't say the actual return value is critical, but the fact that jQuery dies in an unusual way makes debugging hard.

​http://groups.google.com/group/jquery-en/browse_frm/thread/d10bd5d494c488a3#

[dmethvin]

Repro case for .hasClass(".name") bug

[dmethvin]

It occurred to me this morning that an easy fix for hasClass would be:

return this.is( "." + selector.replace(/^\./,"") )

That has the nice effect of doing what the user really meant, too.

[flesler]

No, that's just a custom hack for this situation, not a fix.

Passing .foo to hasClass is with no doubt an error from the developer and we won't be patching things like that.

What I am considering is throwing an error inside the selector engine when an unrecognized filter is found.

[flesler]

This patch throws an error at least on these cases:

  $('foo').hasClass('.bar')
  $('foo..bar')
  $('foo:bar')
  $('foo:bar(baz)')

If you add a space between the tag and the filter it won't throw because that gets handled by find() and not by filter().

[dmethvin]

Confirmed this is fixed in jQuery 1.3.