Bug Tracker

Opened 8 years ago

Closed 7 years ago

#3380 closed bug (fixed)

.hasClass(".name") silently dies

Reported by: dmethvin Owned by: flesler
Priority: major Milestone: 1.3
Component: selector Version: 1.2.6
Keywords: Cc: dmethvin, flesler
Blocked by: Blocking:


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.


Change History (5)

comment:1 Changed 8 years ago by flesler

  • Cc dmethvin flesler added
  • need changed from Review to Patch
  • Owner set to flesler
  • Status changed from new to assigned

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by flesler

This patch throws an error at least on these cases:


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().

comment:5 Changed 7 years ago by dmethvin

  • Resolution set to fixed
  • Status changed from assigned to closed

Confirmed this is fixed in jQuery 1.3.

Note: See TracTickets for help on using tickets.