jsdom_patches.coffee

Fix things that JSDOM doesn't do quite right.

JSDOM intercepts inline event handlers in a similar manner, but doesn't manage window.event property or allow return false.

We're the window. This can happen because inline handlers on the body are proxied to the window.

In-line event handlers rely on window.event

The handler code probably refers to functions declared in the window context, so we need to call run().

Essentially all web browsers (Firefox, Internet Explorer, recent versions of Opera, Safari, Konqueror, and iCab, as a non-exhaustive list) return null when the specified attribute does not exist on the specified element. The DOM specification says that the correct return value in this case is actually the empty string, and some DOM implementations implement this behavior. -- https://developer.mozilla.org/en/DOM/element.getAttribute#Notes

These two patches are required by the above fix.

These properties return empty string when attribute is not set.

These elements have a name property that must return empty string

These elements have a value property that must return empty string

Default behavior for clicking on links: navigate to new URL if specified.

Decide which window to open this link in

If this is a named window, open in existing window or create a new one. This also works for _blank (always open new one)

Make sure to select window as the current one

Fix resource loading to keep track of in-progress requests. Need this to wait for all resources (mainly JavaScript) to complete loading before terminating browser.wait.

Support for iframes that load content when you set the src attribute.

Need to bypass JSDOM's window/document creation and use ours

This is also necessary to prevent JSDOM from messing with window/document

Point IFrame at new location and wait for it to load

Support for opacity style property.

Changing style.height/width affects clientHeight/Weight and offsetHeight/Width

textContent returns the textual content of nodes like text, comment, attribute, but when operating on elements, return only textual content of child text/element nodes.

Form elements collection should allow retrieving individual element by its name, e.g. form.elements["username"] =>

Implement documentElement.contains e.g., if(document.body.contains(el)) { ... } See https://developer.mozilla.org/en-US/docs/DOM/Node.contains

DDOPSON-2012-08-16 -- This implementation is stolen from Sizzle's implementation of 'contains' (around line 1402). We actually can't call Sizzle.contains directly: * Because we define Node.contains, Sizzle will configure it's own "contains" method to call us. (it thinks we are a native browser implementation of "contains") * Thus, if we called Sizzle.contains, it would form an infinite loop. Instead we use Sizzle's fallback implementation of "contains" based on "compareDocumentPosition".

True if element is child of context node or any of its children.

Here comes the tricky part: getDocumentById("foo").querySelectorAll("#foo div") should magically find the div descendant(s) of #foo, although querySelectorAll can never "see" itself.