Search and Top Navigation
#9534 closed bug (notabug)
Opened September 05, 2013 01:03AM UTC
Closed October 18, 2013 05:23PM UTC
Last modified October 18, 2013 11:18PM UTC
Position: positioning against an iframe's contentWindow calculates wrong positions
Reported by: | meyertee | Owned by: | meyertee |
---|---|---|---|
Priority: | minor | Milestone: | none |
Component: | ui.position | Version: | 1.10.3 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
When an iframe's body is larger than the iframe itself, jQuery.height() returns the body-height of the iframe rather than the iframe's height and positioning is off.
By using innerHeight rather than height() we get the expected result.
See: http://jsfiddle.net/meyertee/mzPvj/
It's a bit of an edge case and probably a bug in jQuery. Not sure what the policy is there, but I guess it doesn't hurt to catch the error in jquery-ui. Pull request will follow shortly.
Attachments (0)
Change History (13)
Changed September 05, 2013 01:14AM UTC by comment:1
Changed September 10, 2013 12:49AM UTC by comment:2
owner: | → meyertee |
---|---|
status: | new → pending |
I'm not sure I totally understand this,
height()doesn't take scrollable contents into account - for example http://jsfiddle.net/vFaSX/.
Why wouldn't you just position the element against the
<iframe>in your example?
Changed September 10, 2013 07:44AM UTC by comment:3
status: | pending → new |
---|
My use case is a generic popup/dialog component that positions itself to the center of its containing window, either the top level window or - if it's contained in an iframe - the iframe's window. The code to position it lives in the top level window, it's an iframe without source, so just calling "window" would give me the wrong window..
I noticed the bug when running unit tests for said popup component which position it inside an iframe test fixture.. as I said, a bit of an edge case, and I could work around it by fetching the iframe element rather than its window. Still I'd expect the iframe's window to work the same way than the top level window.
"height() doesn't take scrollable contents into account" -> that's exactly what I'd expect to happen also in the case of iframe.contentWindow, which is a "WindowProxy" according to MDN. The bug is that in that case it takes the scrollable content into account.
I updated my fiddle with some output that show the difference between height() and innerHeight: http://jsfiddle.net/meyertee/mzPvj/
Changed September 10, 2013 01:50PM UTC by comment:4
status: | new → pending |
---|
Ok I think I get it. In the case of
window,
$.fn.heightis equivalent to
innerHeight, but for an
<iframe>'s
window, it is not. Correct?
If that is the case I think this should be a core bug and not something we should workaround in UI.
Changed September 10, 2013 04:50PM UTC by comment:5
status: | pending → new |
---|
That's correct, and I do agree that it's a core bug. The fix seemed minimally invasive though as it's only called for window objects and it's no hack, just closer to the metal. Also I can't patch jQuery in our project and it makes my tests fail... so I wanted to propose it anyway :) Your call!
Changed September 11, 2013 12:28PM UTC by comment:6
I created a core ticket because I'd like to get their perspective first: http://bugs.jquery.com/ticket/14352.
Changed September 11, 2013 12:39PM UTC by comment:7
Thank you for that!
Changed October 18, 2013 04:08PM UTC by comment:8
I've pinged some core devs about http://bugs.jquery.com/ticket/14352 - hopefully we get a response soon. If it gets fixed in Core, we should probably land the PR anyway, but add a
// Supports: jQuery < xstyle comment.
Changed October 18, 2013 04:53PM UTC by comment:9
status: | new → pending |
---|
http://bugs.jquery.com/ticket/14352 was closed as wontfix, since the iframe was in quirksmode. meyertee can you verify your issue isn't caused by quirksmode iframes?
Changed October 18, 2013 05:19PM UTC by comment:10
status: | pending → new |
---|
Well, I can't - the example above and the unit test both use an empty iframe element (no source, no markup attached via Js). If I add the doctype like in the fiddle from the jquery team it works: http://jsfiddle.net/meyertee/mzPvj/12/
I had no idea an empty iframe in a normal document would go into quirksmode.. sorry for wasting everyone's time.
The discrepancy between iframe.contentWindow.innerHeight
and $(iframe.contentWindow).height()
is there though, up to you if you want the fix to support the quirksmode in that case...
Changed October 18, 2013 05:23PM UTC by comment:11
resolution: | → notabug |
---|---|
status: | new → closed |
Changed October 18, 2013 10:22PM UTC by comment:12
Scott already closed, but to answer, no, we don't want to support quirksmode. That only leads to insanity.
When creating an iframe on the fly, try this:
$( "<iframe><!DOCTYPE html><html></html></iframe>" )
Changed October 18, 2013 11:18PM UTC by comment:13
Sanity is better, thanks again for your help!
Created a pull request: https://github.com/jquery/jquery-ui/pull/1073