Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#9534 closed bug (notabug)

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:


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.


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.

Change History (13)

comment:1 Changed 6 years ago by meyertee

comment:2 Changed 6 years ago by tj.vantoll

Owner: set to meyertee
Status: newpending

I'm not sure I totally understand this, height() doesn't take scrollable contents into account - for example

Why wouldn't you just position the element against the <iframe> in your example?

comment:3 Changed 6 years ago by meyertee

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:

comment:4 Changed 6 years ago by tj.vantoll

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.

comment:5 Changed 6 years ago by meyertee

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!

comment:6 Changed 6 years ago by tj.vantoll

I created a core ticket because I'd like to get their perspective first:

comment:7 Changed 6 years ago by meyertee

Thank you for that!

comment:8 Changed 6 years ago by Jörn Zaefferer

I've pinged some core devs about - 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.

comment:9 Changed 6 years ago by Jörn Zaefferer

Status: newpending was closed as wontfix, since the iframe was in quirksmode. meyertee can you verify your issue isn't caused by quirksmode iframes?

comment:10 Changed 6 years ago by meyertee

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:

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...

comment:11 Changed 6 years ago by Scott González

Resolution: notabug
Status: newclosed

comment:12 Changed 6 years ago by Jörn Zaefferer

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>" )

comment:13 Changed 6 years ago by meyertee

Sanity is better, thanks again for your help!

Note: See TracTickets for help on using tickets.