Skip to main content

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 meyertee comment:1

Changed September 10, 2013 12:49AM UTC by tj.vantoll comment:2

owner: → meyertee
status: newpending

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 meyertee comment:3

status: pendingnew

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 tj.vantoll comment:4

status: newpending

Ok I think I get it. In the case of

window
,
$.fn.height
is 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 meyertee comment:5

status: pendingnew

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 tj.vantoll 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 meyertee comment:7

Thank you for that!

Changed October 18, 2013 04:08PM UTC by jzaefferer 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 < x
style comment.

Changed October 18, 2013 04:53PM UTC by jzaefferer comment:9

status: newpending

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 meyertee comment:10

status: pendingnew

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 scottgonzalez comment:11

resolution: → notabug
status: newclosed

Changed October 18, 2013 10:22PM UTC by jzaefferer 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 meyertee comment:13

Sanity is better, thanks again for your help!