Skip to main content

Bug Tracker

Side navigation

#15098 closed bug (fixed)

Opened May 16, 2014 04:56PM UTC

Closed June 15, 2014 11:15PM UTC

Firefox throws NS_ERROR_NOT_AVAILABLE in curCSS

Reported by: Krinkle Owned by: markelog
Priority: blocker Milestone: None
Component: css Version: 1.11.1
Keywords: regression Cc:
Blocked by: Blocking:
Description

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.

Attachments (0)
Change History (9)

Changed May 16, 2014 05:00PM UTC by Krinkle comment:1

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;

Changed May 16, 2014 05:04PM UTC by Krinkle comment:2

Changed May 16, 2014 05:10PM UTC by dmethvin comment:3

_comment0: Ref #1450 which made the change. Heads it's IE, tails it's Firefox. \ 1400260440399848
description: 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.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.
status: newopen

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

Changed May 16, 2014 06:11PM UTC by Krinkle comment:4

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

Changed May 16, 2014 06:29PM UTC by Krinkle comment:5

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.

Changed May 16, 2014 06:43PM UTC by Krinkle comment:6

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.

Changed May 18, 2014 05:01PM UTC by markelog comment:7

owner: → markelog
status: openassigned

Changed May 18, 2014 05:20PM UTC by markelog comment:8

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

Changed June 15, 2014 11:15PM UTC by Oleg Gaidarenko comment:9

resolution: → fixed
status: assignedclosed

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