Skip to main content

Bug Tracker

Side navigation

#12125 closed bug (duplicate)

Opened July 23, 2012 01:41PM UTC

Closed July 23, 2012 02:21PM UTC

Last modified July 23, 2012 02:21PM UTC

Peculiar default in $.contains

Reported by: dwt Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.7.2
Keywords: Cc:
Blocked by: Blocking:
Description

If you look at $.contains, it has a rather peculiar definition.

Some examples:

$.contains({}, 'fnord')

$.contains({}, {})

This of course is against the specification, as it explicitly states that the first element has to be a dom element.

However, this is a) not asserted in the method, and b) some dom elements (such as document) don't always have that .contains() method.

Interesting enough Safari's document doesn't have it, while Chromium does.

So I propose to change the default to false - if the method can't test that something is contained, it should not make the assumption that it is.

Furthermore it would be nice to to assert that the first argument is a dom element as per jQuery's definition of dom elements.

Attachments (0)
Change History (6)

Changed July 23, 2012 01:44PM UTC by dwt comment:1

Sorry forgot to list the results

  $.contains({}, 'fnord') => true
  $.contains({}, {}) => true

Safari version used was: 5.1.7

Changed July 23, 2012 01:45PM UTC by dwt comment:2

The actual bug was observed with this code

 $.contains(document, someDomElement)
which would always return true in Safari, while working properly in other browsers (Chromium).

Changed July 23, 2012 02:10PM UTC by dmethvin comment:3

Seems like this is an inconsistency in Safari, it should be possible to ask if a document contains an element. The .ownerDocument says where it came from but the element can still be detached.

If it is possible to make the default a false I can see that might help some logic, but in general we do not throw assertions for invalid parameters since there are so many ways for things to be invalid.

Changed July 23, 2012 02:18PM UTC by rbu comment:4

it seems this is a duplicate of #11187 and this is already worked around in Sizzle HEAD. If an element does not have contains, the new implementation walks up the parent chain from the child by hand.

Changed July 23, 2012 02:21PM UTC by dmethvin comment:5

resolution: → duplicate
status: newclosed

Yes indeedy! A test case would have shown that quickly. :)

Changed July 23, 2012 02:21PM UTC by dmethvin comment:6

Duplicate of #11187.