Both leaflets are unfolded by default, and fold down if the window is
too small, hence the conversation list's and viewer's action bar
revealers must be hidden by default to match,
Convert Components.ConversationActions to a widget that encapsulates
selectively visible conversations action groups. Use multiple instances
of that in preference to a single shared instance that gets re-parented
as the responsive UI adjusts.
Flatten the custom widget hierarchy a bit by merging the
`ConversationActionBar` and `ConversationHeaderbar` widgets into
`MainToolbar` itself.
Since commit 6a0ad721 landed the client can no longer reply on
pre-filling JS page state before loading the message body HTML, since
it would be cleared when the JS page state is initialised in the
window-object-cleared handler.
Instead, set the load remote flag as a GObject data property on the
WebKit.WebPage object in the web process via the extension, and consult
that when determining whether to allow loading remote content.
Fixes#1170
HdyApplicationWindow moves the titlebar into the content area of the
window which allows us to split the current main-titlebar and move the
parts directly into the leaflets without the need of swipe groups nor
size groups.
Add private HeaderRow and EntryHeaderRow widgets for displaying editable
headers in the composer, convert to using that to wrap up common
properties and functionality for each of the header rows.
Rename `UpgradeDialog` to `DatabaseManager` since it's not actually a
dialog, move it into the APplication package. Replace old Glade UI file
with a custom built dialog since it's trivial and so we can make it
modal for a main window.
Fixes#1007
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.
