IFRAME not taking all height on HTML mail preview

[nexces]

IFRAME height defaults to browser default which is 150px on chrome and in effect mail preview is limited to a small scrollable stripe.
My fix was to set IFRAME height to 100%.

[ian-kent]

Thanks @nexces - I tried with it set to 100% and it didn't seem to work consistently.

It currently attempts to resize the IFRAME when you select a message, so it breaks if you open developer tools, or resize the window, once its already in preview mode.

But aside from that, it should work - I'll have a look today.

[nexces]

I don't know how tabs are handled but div.tab-content has fixed height that is set just once (on page load) and does not update when window is resized.
If IFRAME is set to width: 100%; and height: 100%; it occupies whole parent (div.tab-content).
If there is some JS function that is responsible for setting up this height it should also be launched on 'resize' and 'orientationchange' window events.
That should do the trick.
Also with IFRAME inside div.tab-content there is no need for div.tab-content to have overflow-y: scroll;

[ian-kent]

resizePreview in MailHog-UI/assets/js/controllers.js is called in selectMessage and toggleHeaders, which updates the height of .tab-content and .tab-content .tab-pane

It might be a timing bug though - AngularJS doesn't (or, didn't) give any straightforward way to hook into "after rendering the changes i'm about to make", i.e., to be able to wait until AngularJS has rendered the tabs and panes before attempting to resize them. For me, pushing the resize call to the end of the event loop (with a timer set to 0) was enough to let the browser finish rendering, but that might not be enough for everyone.

The overflow-y: scroll is used for the other panes, e.g. plain text and MIME, which aren't contained in an IFRAME. That could all do with a bit of cleaning up!

You're right about resize - none of it hooks into any window events, which does mean resizing or opening developer tools etc will break it. The UI was mostly inherited from the old MailHog, and the recent rewrite probably didn't go far enough.

Ideally I'd rather handle all of this without needing Javascript to avoid all this mess 😄

I'll have a look at it asap!

[nexces]

To be honest I didn't analyze how you've done tabs - is it your own solution or is it some kind of plugin/library.
If I would like to make resizeable content I would go with CSS absolute positioning.
But there are drawbacks - you need to assume that (in case of MailHog UI) left and top side of resizeable content (message preview) is static in terms of size.
For left side it's easy - it can be left as it is. However top side can cause troubles - "Subject" and "To" can go multiline and it breaks "static" assumption.
You can always go with text-overflow:ellipsis on that fields and provide some tooltip, but someone might want to copy all that field content (i think it's an edge case, but might not be the only case) and tooltip might not allow it.

So... that was me thinking out loud :D

EDIT:
Just to make it clear ;)
left side: folders and Jim
top side: header, buttons, "From", "Subject", "To" fields, tabs

[ian-kent]

The tabs are done with bootstrap, hooked into with angulars ng-click binding - AngularUI might provide a nicer solution! I think it was the message headers which caused me the problem - the show/hide full headers button - but I can't really remember.

I'll have another go at fixing it - there's a lot of old unnecessary code and CSS left in there from the previous UI which I've been meaning to remove, cleaning all that up might make it easier to fix!

[ian-kent]

I think this is fixed with the latest UI changes - reopen if its still a problem 😄

[hanoii]

I am still having height issues with the latest release.

[devnix]

Me too, specially when I click the browser notification, it leads me to an iframe with 0 height.

[JshGrn]

This is still an issue 4 years later unless I am missing something