Opened 9 years ago
Closed 9 years ago
#15098 closed bug (fixed)
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 (last modified by )
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.
Change History (9)
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
Downstream bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=65373
comment:3 Changed 9 years ago by
Description: | modified (diff) |
---|---|
Status: | new → open |
Ref #14150 which made the change. Heads it's IE, tails it's Firefox.
comment:5 Changed 9 years ago by
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.
comment:6 Changed 9 years ago by
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.
comment:7 Changed 9 years ago by
Owner: | set to markelog |
---|---|
Status: | open → assigned |
comment:8 Changed 9 years ago by
Issue in mozilla bug tracker – https://bugzilla.mozilla.org/show_bug.cgi?id=1012413
comment:9 Changed 9 years ago by
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
jQuery 1.11.1's jQuery.fn.css