Using `whitespace: pre-wrap` to format plain text email sometimes
causes additional width to be allocated by the plain text blocks that
then does not get used due to the constraints on the HTML element.
The allocated space remains however and hence an un-needed horizontal
scrollbar appears.
Using `break-spaces` instead seems to help since it allows breaks after
a space character, leading to the additional space not otherwise being
allocated.
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.
Use some more obvious CSS to ensure we can get an accurate idea of the
content height for sizing the web view and that the body fits the
web view's width.
Rather than guessing when the height might change by using a number
of different event listeners, use a ResizeObserver to get direct
notifications of any changes to the HTML element's size.
Now that the `:focus-within` pseudoclass is supported, use this rather
than some custom JS to update custom HTML classes. This also prevents
spurious mutation events from firing.
Move selection changed event listener into JS so it doesn't have to
cross the JS/native boundary twice.
Move sending remote load blocked from JS to the extension since we can
do that directly now and again so the JS/native boundary doesn't need
to be double-crossed again.
Define a vala-backed JS class in the extension and make that available
to pages when they are registered. Add some helper JS to PageState for
defining message sending functions. Listen for these in
Components.WebView and dispatch to the registered callback for it.
Update web extension to check for errors when invoking page state
methods and pass a message back if found. Check for this, decode and
throw a vala error in the WebView if found.
Use WebKitGTK UserMessage objects for invoking JS methods rather than
serialising to JS strings and running those. This is possibly slightly
less efficient, but removes the onus on serialising to and parsing from
JS and once switched over from message handlers to UserMessage objects
will be using a single uniform IPC interface for both.
This moves the actions from the headerbar to the action bar at the
bottom of the conversations list when multiple conversations are
selected. This changes is needed so that the user can still interact
with the conversations when folded.
This also hides the actions from the Headerbar and action bar when
no conversation is selected.
This creates a new object that contain the 4 groups of actions that used
to be in the conversation-viewer headerbar.
This allows the widgets to be moved to differen locations, e.g. to an
action bar that will be added in a later commit.
Create a new Composer.Editor widget and move all body web view and
action bar related code from the main widget there.
This helps to clearly delineate concerns of the two classes, it
substantially reduces the complexity of the main widget, and should
reduce the odds of further breakage like that fixed by the previous
commit less likely in the future.
Use CSS instead of widget props to ensure widgets have sufficient
white space.
This will allow adding additional action bars (e.g. by plugins) in a
more straight-forward manner.
Now that InfoBarStack supports a priority queue, use that for folder
and email stacks, and set the required priority property when
constructing info bars for plugins, so that the highest priority
info bar is always shown.
- Move single-key shortcuts to their own section
- break the shortcuts list into two columns
- mention that single-key shortcuts need to be enabled in preferences
Remove stock infobars from ConversationEmail and ConversationMessage
builder files. Use common ComponentsInfobar for remote image loading
infobar. Use Components.InfoBarStack in ConversationMessage for plugin
support.
