Height not resizing correctly when iframe content has proportional sized div

[regauser]

Hi

The content on my iframe needs to be always at a 16:9 ratio of width:height.

Unfortunately, when I use proportional content like this, my iframe height is not getting resized correctly by iframeresizer.

I have setup two demos using different methods to create the proportional div:
http://www.wavyd.com/tests/iframeresize-proportional/v1-consumer.htm
http://www.wavyd.com/tests/iframeresize-proportional/v2-consumer.htm

Both demos have a 16:9 ratio box (red), one line of text content under it, and a 1px black border applied to the bottom of the 'body' so it is clear where the iframe should end.

With both of demos, when the page loads, press one of the buttons to call 'iFrameResize' using a particular 'heightCalculationMethod'.

At this first resize, in Chrome the iframe is resized correctly.

In IE11, however, it will only do this first resize correctly if the resize doesn't result in the consumer page needing a vertical scrollbar.

Next, with either browser, when you resize the window, you can see the iframe resizing, but usually when you let go of the mouse, it has not applied the correct height. You will see that the black border is either hidden as the iframe is too small, or has white space under it as the iframe is too big.

Oddly, on either browser, if you then 'click' anywhere on the iframe, this event always resizes the iframe correctly.

The first of the two demos uses an absolute positioned child. So, as recommended in your absolute position example, I have tried each of the different 'heightCalculationMethod', but with no success.

The second demo doesn't use absolute positioning, but still has problems with setting the height correctly. Again I have tried each of the different 'heightCalculationMethod' values.

I hope you can help.

David

[davidjbradshaw]

Just tried this in Chrome on the Mac and I see what you mean, that's an interesting one, I think the issue is that it only processes calls from the resize event every 100ms and I see this issue if I resize the window very quickly.

Can you give this a go with the uncompressed version, and uncomment out line 164, to see if that fixes the issue for you.

Click is one of the event handlers that cause the resize check to run. So that is expected behaviour.

[regauser]

Hi David. Thanks for your prompt response.

What seems strange is that once I've let go of the mouse, and it has resized the height incorrectly, it is then left like that indefinitely until some other event (mouse click, another resize etc) forces it to check the size again.

I don't know if this is the planned behaviour, but it seems the plugin has stopped checking whether the iframe size is correct. It feels like it needs some kind of setTimeout to repeatedly check if the iframe height is correct.

With regards to your uncommenting suggestion... I tried this locally, but unfortunately uncommenting line 164 of iframeResizer.contentWindow.js hasn't made a difference.

Is this because the 'mouseup' event is attached to the content window, whereas when resizing the browser by dragging the edges, the mouse is focussed on the parent window?

David

[davidjbradshaw]

I guess that is the issue with MouseUp. The only other thing I can suggest
is setting the interval option to -32, as this will force it to run in all
browsers.

Going forward I might consider a patch that rechecks the size 16ms after
the last resize event.

On Wed, Mar 11, 2015 at 10:11 AM, regauser notifications@github.com wrote:

Hi David. Thanks for your prompt response.

Unfortunately, uncommenting line 164 of iframeResizer.contentWindow.js
hasn't made a difference.

Is this because the 'mouseup' event is attached to the content window,
whereas when resizing the browser by dragging the edges, the mouse is
focussed on the parent window?

David

—
Reply to this email directly or view it on GitHub
#163 (comment)
.

David J. Bradshaw )'( dave@bradshaw.net

[regauser]

With regards to my original demos, I find that while resizing my browser window, the speed of moving my mouse only makes a difference to how much the height is wrong by, not how often it is wrong. When moving the mouse slowly, it is usually wrong by only a pixel or two. When moving quickly, there can be much larger errors.

Is it possible that the issue is because my CSS has height that is in percentages, and so has decimal pixel sizes? Could that be tricking your code into thinking a resize hasn't happened when it has?

I have tried your suggestion of using 'interval': -32

This works great for the most part, except for a particular problem with scrollbars. I have made a demo below...
http://www.wavyd.com/tests/iframeresize-proportional/v1-consumer-interval.htm

Click e.g. the 'bodyOffset' button, then start with a tall window that has no vertical scrollbar. Now shrink the window height until my buttons go just off the bottom, and so the vertical scrollbar first appears. At this point the page gets stuck in an infinite loop of flickering of hiding and showing the scrollbar.

For anyone else reading this, this scrollbar issue can be avoided by forcing the page to always display a vertical scrollbar. Unfortunately, as our own content will be placed on our clients parent pages, we can't dictate this design decision to them.

I like your patch idea of doing a recheck, but is there a risk that this will also cause the infinite loop above?

Thanks again.

David

[davidjbradshaw]

Not seeing the flicker in Chrome on my Mac. I guess the issue is Window adding and removing the scroll bar changes the width of the page and that cause the loop. This is a design fail in Windows, the only option is to always have the scroll bar.

As for the speed, the resize event only fires every 100ms, during that time other resizes are ignored, to prevent a loop where the code on the parent resizing the iframe causes the iFrame to think it's been resized again.

D.

[davidjbradshaw]

This should hopefully work much better in v2.8.6