iframe resizer height calculation method 'max' causing jittery behaviour

[mdgbayly]

We are seeing jittery behaviour across multiple browsers with the iframe resizer height calculations.
It seems to be caused by the use of the 'max' height calculation method. If we switch back to the default 'bodyOffset' the problem goes away.

The method was changed to 'max' a few months ago in response to another issue, although I don't recall the full details of why (maybe for IE10 issues which we don't even support now?)

Our problem seems to be caused by crazy resizing cycles that happen in response to some css transitions that are causing the iframe resizer to temporarily switch the height calc method, send a 'reset' event and then switch back to the set height calc method. I don't fully understand why its happening, but 'max' seems sub-optimal.

I'd like to submit PRs so we can at least configure the method it uses from the FRA control for the particular app in the LMS.

I was thinking of adding a new attribute to the IFramePageView class in the app loader similar to the existing 'height' property to allow the height calculation method to be passed down the iframe resizer host plugin.

Thoughts?

[omsmith]

Just adding for context: #83

[dlockhart]

@mtjandra, do you recall if the original need for "max" in #83 was only for IE10? We no longer need to support it.

[mtjandra]

Originally had to change the heightCalculation away from bodyOffset due to text being cut off (should be able to reproduce with this project). I remember seeing the text cut off in Firefox, but I believe it was observed in Chrome and IE as well. Yes we switched to max because the documentation makes this suggestion for IE10 and below. If IE10 is no longer supported the document suggests taggedElement or lowestElement when the default does not work.

[mdgbayly]

I guess another option is that we allow the FRA to override the height calc method from the client side. Another read of the docs and that looks like it's possible. Given that iframe resizer supports different approaches, I think we should allow apps to choose the approach that works best for them. bodyOffset seems like the most performant, so in the interest of eeking out every last bit of speed - I'd like to try that. I'll investigate what it would take to enable the height calc method from the client.

[jcalfee]

I have the same issue. My case is a 3rd party iframe that by default its size is not quite high enough. And here again, the "max" figures this out but introduces the jitter.

What about a simple tolerance for max? It is not terrible to have a little extra space after an iframe. Keep sticking with a max unless it is reduce by more than the tolerance parameter. That should stop all the event looping. If that errors it is only a matter of the user provided tolerance which is not much. That is much better than having 1/3 of a button. This would not introduce any delay in a normal max update.

Also, a user provided debounce in milliseconds that errors on the side of max looks like it would fix it too. That would introduce a delay for a desired re-max. My case looks like 170ms might work fine so it would not be much.

[jcalfee]

Related: davidjbradshaw/iframe-resizer#1065