[geary/mjog/283-plain-text-whitespace-fixes: 3/4] ui/conversation-web-view.css: Work around oversized email body height

[Michael Gratton <mjog src gnome org>]

commit 6e283ef13caacbf17eee1c73f0351469d7867625
Author: Michael Gratton <mike vee net>
Date:   Sat Oct 17 13:38:16 2020 +1100

    ui/conversation-web-view.css: Work around oversized email body height
    
    Sometimes when loading an email body, the viewport for the web view
    will be set to 0 (when the web view is hidden or not yet laid out in
    the widget hierarchy?). When this happens, since the width of the body
    is specified as 100vw, the content width is reduced to the absolute
    minimum and hence the content height is stretched right out. Then, when
    the web view is displayed, the viewport width increases but the extra
    whitespace is never reclaimed (scrollHeight never goes down), so the
    height of the web view remains way too large, causing large amounts of
    whitespace at the end of the email message (i.e. #283).
    
    To work around this, set a min width for the HTML element so the initial
    height of the email body isn't too badly wrong.

 ui/conversation-web-view.css | 9 +++++++++
 1 file changed, 9 insertions(+)
---
diff --git a/ui/conversation-web-view.css b/ui/conversation-web-view.css
index 3c1929f29..8b0ef421b 100644
--- a/ui/conversation-web-view.css
+++ b/ui/conversation-web-view.css
@@ -23,6 +23,15 @@ html {
   width: 100vw !important;
   height: max-content !important;
 
+  /* Despite the fact that the width must always be defined by the
+  viewport, the viewport width will be 0 if the email is loaded before
+  its WebView is laid out in the widget hierarchy. As a workaround, to
+  prevent this causing the email being squished down to is minimum
+  width and hence being stretched right out in height, set a
+  reasonable minimum width. See
+  https://gitlab.gnome.org/GNOME/geary/-/issues/283 */
+  min-width: 400px !important;
+
   /* Lock down the box sizing just enough so that the width and height
   constraints above work as expected, and so the element's
   scrollHeight is accurate. */