Side navigation
#14150 closed bug (fixed)
Opened July 18, 2013 04:23PM UTC
Closed August 19, 2013 04:11PM UTC
Last modified June 15, 2014 11:15PM UTC
IE9-10 curCSS => "Interface not supported" in for popups (and probably frames)
| Reported by: | price.c@gmail.com | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.11/2.1 |
| Component: | css | Version: | 1.8.0 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
The fix for bug #10373 in commit f7ee1f6e59f0b465f5f64bf6ac52108e445efaac broke the getComputedStyle functionality for elements residing in popups or frames accessed from the main document.
The following jsfiddle demonstrates the problem, choose jQuery 1.7.2 and the problem disappears.
This was also reported by a comment on #10373 http://bugs.jquery.com/ticket/10373#comment:7.
Attachments (0)
Change History (10)
Changed July 18, 2013 05:42PM UTC by comment:1
| status: | new → open |
|---|
Changed July 18, 2013 05:58PM UTC by comment:2
I've patched it on the 1.8-stable branch on my fork on GitHub (chrisprice) but I'm not sure how to add tests. It doesn't seem to be reproducible in an iframe.
Changed July 18, 2013 06:08PM UTC by comment:3
On the general need, since we've talked about requiring a browser-like window object for environments like node.js it does seem rather annoying. However, is there any browser-like simulator for node that could handle $(elem).width() anyway? In the cases where I've used jQuery I've just wanted selection and traversing, perhaps you could add manipulation to that but the rest seems too browser specific to be used.
It sounds like the crash only happens in a window.open window, I'm not sure we want to add a test that requires calling it. Ensuring that document.defaultView works may be enough?
The currently active branches are 1.x-master and master (which is 2.x). The PR should be against one of those, ideally both but if it's easy to cherry pick there should be no problem with just having one PR for now.
Changed July 18, 2013 07:04PM UTC by comment:4
Changed July 18, 2013 07:16PM UTC by comment:5
@dmethvin That's fair, but we probably don't want to crash on .css( property ). As for reproducibility, I can confirm that the error does not manifest in iframes: http://jsfiddle.net/VYNj9/2/
As for testing... man, that's tough. If we don't put in a window.open, we're likely to see a regression at some point, but if we do, we're likely to have other problems with it.
Changed July 18, 2013 07:23PM UTC by comment:6
#12235 is the original reason for window.getComputedStyle( elem, null ), but we never questioned the reporter about what ey was doing with CSS on jsdom to run afoul of the bug.
Changed August 13, 2013 02:09PM UTC by comment:7
| component: | unfiled → css |
|---|---|
| milestone: | None → 1.10.3/2.0.4 |
| priority: | undecided → low |
Changed August 19, 2013 04:11PM UTC by comment:8
| resolution: | → fixed |
|---|---|
| status: | open → closed |
Fix #14150: revert to ownerDocument.defaultView.getComputedStyle. Close gh-1311.
Changeset: 3e3680c2cdc524ee9194ef27fdce318cf301144c
Changed September 16, 2013 01:21AM UTC by comment:9
| milestone: | 1.10.3/2.0.4 → 1.11/2.1 |
|---|
Bulk update for new milestone
Changed June 15, 2014 11:15PM UTC by comment:10
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
Seems like a reasonable one-line change to me, though I wish we had better non-browser testing to be sure.