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 comment:1
Changed May 16, 2014 05:04PM UTC by comment:2
Downstream bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=65373
Changed May 16, 2014 05:10PM UTC by 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: | new → open |
Ref #14150 which made the change. Heads it's IE, tails it's Firefox.
Changed May 16, 2014 06:11PM UTC by comment:4
Isolated example: http://jsfiddle.net/LLeLa/
Changed May 16, 2014 06:29PM UTC by comment:5
Reduced even further, including comparison to window.getComputedStyle and node.ownerDocumenet.defaultView.getComputedStyle.
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 comment:6
I'm not sure why jQuery's invocation is different.
Final case from me today:
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 comment:7
| owner: | → markelog |
|---|---|
| status: | open → assigned |
Changed May 18, 2014 05:20PM UTC by comment:8
Issue in mozilla bug tracker – https://bugzilla.mozilla.org/show_bug.cgi?id=1012413
Changed June 15, 2014 11:15PM UTC by comment:9
| resolution: | → fixed |
|---|---|
| status: | assigned → closed |
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
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;