Firefox throws NS_ERROR_NOT_AVAILABLE in curCSS

[Krinkle]

After upgrading from jQuery 1.8.3 to 1.11.1, I've started seeing various cases where in Firefox an NS_ERROR_NOT_AVAILABLE exception is thrown from curCSS.

I suspect this is related to the change in how we call getComputedStyle.

@curCSS

ret = computed ? computed.getPropertyValue( name ) || computed[ name ] : undefined;

It used to use window.getComputedStyle regardless of which document owned the node, and it now uses the (seemingly more correct) ownerDocument.defaultView to access the relevant window (e.g. when inside an iframe or popup) and call getComputedStyle there.

[Krinkle]

Inside .css():

jQuery 1.8.3's jQuery.fn.css

// curCSS
 computed = window.getComputedStyle( elem, null ),
 style = elem.style
 if ( computed ) {
   // getPropertyValue is needed for .css('filter') in IE9, see #12537
   ret = computed.getPropertyValue( name ) || computed[ name ];

jQuery 1.11.1's jQuery.fn.css

// getStyles
  return elem.ownerDocument.defaultView.getComputedStyle( elem, null );

// curCSS
  computed = .. || getStyles( elem );
  style = elem.style

  // getPropertyValue is needed for .css('filter') in IE9, see #12537
  ret = computed ? computed.getPropertyValue( name ) || computed[ name ] : undefined;

[Krinkle]

Downstream bug report: ​https://bugzilla.wikimedia.org/show_bug.cgi?id=65373

[dmethvin]

Ref #14150 which made the change. Heads it's IE, tails it's Firefox.

[Krinkle]

Isolated example: ​http://jsfiddle.net/LLeLa/

[Krinkle]

Reduced even further, including comparison to window.getComputedStyle and node.ownerDocumenet.defaultView.getComputedStyle.

​http://jsfiddle.net/PK3YN/

Looks like when using either of those plainly, there is no exception, just null. Whereas jQuery somehow manages to make it throw.

[Krinkle]

I'm not sure why jQuery's invocation is different.

Final case from me today:

​http://jsfiddle.net/eXt63/

It tests:

• jQuery
• window.getComputedStyle: sub
• window.getComputedStyle: getPropertyValue()
• node.ownerDocument.defaultView.getComputedStyles: sub
• node.ownerDocument.defaultView.getComputedStyles: getPropertyValue()
• A pretend-to-be-jQuery that does what curCSS does

In Chrome regardless of step 2 (display none), it outputs 6 times "ltr".

In Firefox, without step 2 (display none), it outputs 6 times "ltr". As it is on ​http://jsfiddle.net/eXt63/

(with display none), it outputs:

jQuery: [Exception... "Component is not available" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: ​http://code.jquery.com/jquery-1.11.0.js :: curCSS :: line 6123" data: no]

window.getComputedStyle:

• sub: ltr
• getPropertyValue(): ltr

node.ownerDocument.defaultView.getComputedStyle: null null

jQuery pretend: undefined --

So it looks like jQuery is doing something extra that makes Firefox throw, it doesn't have to.

[markelog]

PR – ​https://github.com/jquery/jquery/pull/1583

[markelog]

Issue in mozilla bug tracker – ​https://bugzilla.mozilla.org/show_bug.cgi?id=1012413

[Oleg Gaidarenko]

CSS: Do not throw on frame elements in FF

IE9-10 throws on elements created in popups (see #14150), FF meanwhile throws on frame elements through "defaultView.getComputedStyle" (see #15098)

Use "defaultView" if in the popup which would fix IE issue, use "window.getComputedStyle" which would fix FF issue.

And everybody wins, except performance, but who cares right?

Fixes #15098 Closes gh-1583

Changeset: e488d985cfb10ab8c684bbc6a9b8ff3eae23bf83