As of WebKitGTK 2.40, enable-frame-flattening is no longer supported,
the property does nothing, resulting in all messages in the thread
viewer being cut off at around 150px, making all long messages
unreadable.

I initially had a look into seeing whether the iframe height could be
set programmatically with `webkit_dom_html_iframe_element_set_height`
from the content of the iframe via `webkit_dom_element_get_scroll_height`.
However nothing worked at page load time of an email thread, the content
scroll height remained at 150 throughout the entire
`ThreadView_on_load_changed` pass (because iframes are rendered lazily
after the main window thread has finished?  Can't think of any other
reason why this was observed). The scroll height was only found to
update after the thread had finished loading, and triggering a hide/show
toggle on each message.

Another option woruld be to use the JavaScriptCore API, and have all the
logic to manipulate the height of the iframe in JS. Two possible
problems with this: Firstly `enable-javascript` is explicitly disabled
in Astroid's WebKit settings; second, potentially all of the
`webextension` code may need to be rewritten in JS - given the huge
amount of deprecation warnings when building Astroid, this likely will
probably have to be done in anger at some point in the future anyway.

I gave up going down the pass of manipulating the iframe after setting
`srcdoc`, and instead replaced the iframe with a div instead. CSS has
been fixed up and theme version bumped as it would be a breaking change
for all existing users that override the theme of the UI.

I can't see any concernable difference between before and after when
viewing both text/html and text/plain messages, though it is difficult
to gauge as my starting point is broken messages.

The `AstroidExtension::reload_images` code path is the least tested of
all the changes. The minimal check I did to see whether the logic is
still fine was to send myself an email with a CID attachment, and
observe it render correctly after pressing C-i in thread view.

As far as this change is concerned, this is one way to fix astroidmail#720 that
suits my use of Astroid. I'm not convinced that it is the correct way to
go about it though, as I have no reason to dismiss the rationale for
using iframes in the first place - see comments delete by this patch
that make reference to style issues, deadlocks and security concerns by
not having the content contained to its own iframe.

As of WebKitGTK 2.40, enable-frame-flattening is no longer supported,
the property does nothing, resulting in all messages in the thread
viewer being cut off at around 150px, making all long messages
unreadable.

I initially had a look into seeing whether the iframe height could be
set programmatically with `webkit_dom_html_iframe_element_set_height`
from the content of the iframe via `webkit_dom_element_get_scroll_height`.
However nothing worked at page load time of an email thread, the content
scroll height remained at 150 throughout the entire
`ThreadView_on_load_changed` pass (because iframes are rendered lazily
after the main window thread has finished?  Can't think of any other
reason why this was observed). The scroll height was only found to
update after the thread had finished loading, and triggering a hide/show
toggle on each message.

Another option would be to use the JavaScriptCore API, and have all the
logic to manipulate the height of the iframe in JS. Two possible
problems with this: Firstly `enable-javascript` is explicitly disabled
in Astroid's WebKit settings; second, potentially all of the
`webextension` code may need to be rewritten in JS - given the huge
amount of deprecation warnings when building Astroid, this likely will
probably have to be done in anger at some point in the future anyway.

I gave up going down the pass of manipulating the iframe after setting
`srcdoc`, and instead replaced the iframe with a div instead. CSS has
been fixed up and theme version bumped as it would be a breaking change
for all existing users that override the theme of the UI.

I can't see any concernable difference between before and after when
viewing both text/html and text/plain messages, though it is difficult
to gauge as my starting point is broken messages.

The `AstroidExtension::reload_images` code path is the least tested of
all the changes. The minimal check I did to see whether the logic is
still fine was to send myself an email with a CID attachment, and
observe it render correctly after pressing C-i in thread view.

As far as this change is concerned, this is one way to fix astroidmail#720 that
suits my use of Astroid. I'm not convinced that it is the correct way to
go about it though, as I have no reason to dismiss the rationale for
using iframes in the first place - see comments delete by this patch
that make reference to style issues, deadlocks and security concerns by
not having the content contained to its own iframe.

As of WebKitGTK 2.40, enable-frame-flattening is no longer supported,
the property does nothing, resulting in all messages in the thread
viewer being cut off at around 150px, making all long messages
unreadable.

I initially had a look into seeing whether the iframe height could be
set programmatically with `webkit_dom_html_iframe_element_set_height`
from the content of the iframe via `webkit_dom_element_get_scroll_height`.
However nothing worked at page load time of an email thread, the content
scroll height remained at 150 throughout the entire
`ThreadView_on_load_changed` pass (because iframes are rendered lazily
after the main window thread has finished?  Can't think of any other
reason why this was observed). The scroll height was only found to
update after the thread had finished loading, and triggering a hide/show
toggle on each message.

Another option would be to use the JavaScriptCore API, and have all the
logic to manipulate the height of the iframe in JS. Two possible
problems with this: Firstly `enable-javascript` is explicitly disabled
in Astroid's WebKit settings; second, potentially all of the
`webextension` code may need to be rewritten in JS - given the huge
amount of deprecation warnings when building Astroid, this likely will
have to be done in anger at some point in the future anyway.

I gave up going down the pass of manipulating the iframe after setting
`srcdoc`, and instead replaced the iframe with a div instead. CSS has
been fixed up and theme version bumped as it would be a breaking change
for all existing users that override the theme of the UI.

I can't see any concernable difference between before and after when
viewing both text/html and text/plain messages, though it is difficult
to gauge as my starting point is broken messages.

The `AstroidExtension::reload_images` code path is the least tested of
all the changes. The minimal check I did to see whether the logic is
still fine was to send myself an email with a CID attachment, and
observe it render correctly after pressing C-i in thread view.

As far as this change is concerned, this is one way to fix astroidmail#720 that
suits my use of Astroid. I'm not convinced that it is the correct way to
go about it though, as I have no reason to dismiss the rationale for
using iframes in the first place - see comments delete by this patch
that make reference to style issues, deadlocks and security concerns by
not having the content contained to its own iframe.

As of WebKitGTK 2.40, enable-frame-flattening is no longer supported,
the property does nothing, resulting in all messages in the thread
viewer being cut off at around 150px, making all long messages
unreadable.

I initially had a look into seeing whether the iframe height could be
set programmatically with `webkit_dom_html_iframe_element_set_height`
from the content of the iframe via `webkit_dom_element_get_scroll_height`.
However nothing worked at page load time of an email thread, the content
scroll height remained at 150 throughout the entire
`ThreadView_on_load_changed` pass (because iframes are rendered lazily
after the main window thread has finished?  Can't think of any other
reason why this was observed). The scroll height was only found to
update after the thread had finished loading, and triggering a hide/show
toggle on each message.

Another option would be to use the JavaScriptCore API, and have all the
logic to manipulate the height of the iframe in JS. Two possible
problems with this: Firstly `enable-javascript` is explicitly disabled
in Astroid's WebKit settings; second, potentially all of the
`webextension` code may need to be rewritten in JS - given the huge
amount of deprecation warnings when building Astroid, this likely will
have to be done in anger at some point in the future anyway.

I gave up going down the path of manipulating the iframe after setting
`srcdoc`, and instead replaced the iframe with a div instead. CSS has
been fixed up and theme version bumped as it would be a breaking change
for all existing users that override the theme of the UI.

I can't see any concernable difference between before and after when
viewing both text/html and text/plain messages, though it is difficult
to gauge as my starting point is broken messages.

The `AstroidExtension::reload_images` code path is the least tested of
all the changes. The minimal check I did to see whether the logic is
still fine was to send myself an email with a CID attachment, and
observe it render correctly after pressing C-i in thread view.

As far as this change is concerned, this is one way to fix astroidmail#720 that
suits my use of Astroid. I'm not convinced that it is the correct way to
go about it though, as I have no reason to dismiss the rationale for
using iframes in the first place - see comments delete by this patch
that make reference to style issues, deadlocks and security concerns by
not having the content contained to its own iframe.

As of WebKitGTK 2.40, enable-frame-flattening is no longer supported,
the property does nothing, resulting in all messages in the thread
viewer being cut off at around 150px, making all long messages
unreadable.

I initially had a look into seeing whether the iframe height could be
set programmatically with `webkit_dom_html_iframe_element_set_height`
from the content of the iframe via `webkit_dom_element_get_scroll_height`.
However nothing worked at page load time of an email thread, the content
scroll height remained at 150 throughout the entire
`ThreadView_on_load_changed` pass (because iframes are rendered lazily
after the main window thread has finished?  Can't think of any other
reason why this was observed). The scroll height was only found to
update after the thread had finished loading, and triggering a hide/show
toggle on each message.

Another option would be to use the JavaScriptCore API, and have all the
logic to manipulate the height of the iframe in JS. Two possible
problems with this: Firstly `enable-javascript` is explicitly disabled
in Astroid's WebKit settings; second, potentially all of the
`webextension` code may need to be rewritten in JS - given the huge
amount of deprecation warnings when building Astroid, this likely will
have to be done in anger at some point in the future anyway.

I gave up going down the path of manipulating the iframe after setting
`srcdoc`, and replaced the iframe with a div instead. CSS has been fixed
up and theme version bumped as it would be a breaking change for all
existing users that override the theme of the UI.

I can't see any concernable difference between before and after when
viewing both text/html and text/plain messages, though it is difficult
to gauge as my starting point is broken messages.

The `AstroidExtension::reload_images` code path is the least tested of
all the changes. The minimal check I did to see whether the logic is
still fine was to send myself an email with a CID attachment, and
observe it render correctly after pressing C-i in thread view.

As far as this change is concerned, this is one way to fix astroidmail#720 that
suits my use of Astroid. I'm not convinced that it is the correct way to
go about it though, as I have no reason to dismiss the rationale for
using iframes in the first place - see comments delete by this patch
that make reference to style issues, deadlocks and security concerns by
not having the content contained to its own iframe.

As of WebKitGTK 2.40, enable-frame-flattening is no longer supported,
the property does nothing, resulting in all messages in the thread
viewer being cut off at around 150px, making all long messages
unreadable.

I initially had a look into seeing whether the iframe height could be
set programmatically with `webkit_dom_html_iframe_element_set_height`
from the content of the iframe via `webkit_dom_element_get_scroll_height`.
However nothing worked at page load time of an email thread, the content
scroll height remained at 150 throughout the entire
`ThreadView_on_load_changed` pass (because iframes are rendered lazily
after the main window thread has finished?  Can't think of any other
reason why this was observed). The scroll height was only found to
update after the thread had finished loading, and triggering a hide/show
toggle on each message.

Another option would be to use the JavaScriptCore API, and have all the
logic to manipulate the height of the iframe in JS. Two possible
problems with this: Firstly `enable-javascript` is explicitly disabled
in Astroid's WebKit settings; second, potentially all of the
`webextension` code may need to be rewritten in JS - given the huge
amount of deprecation warnings when building Astroid, this likely will
have to be done in anger at some point in the future anyway.

I gave up going down the path of manipulating the iframe after setting
`srcdoc`, and replaced the iframe with a div instead. CSS has been fixed
up and theme version bumped as it would be a breaking change for all
existing users that override the theme of the UI.

I can't see any concernable difference between before and after when
viewing both text/html and text/plain messages, though it is difficult
to gauge as my starting point is broken messages.

The `AstroidExtension::reload_images` code path is the least tested of
all the changes. The minimal check I did to see whether the logic is
still fine was to send myself an email with a CID attachment, and
observe it render correctly after pressing C-i in thread view.

As far as this change is concerned, this is one way to fix astroidmail#720 that
suits my use of Astroid. I'm not convinced that it is the correct way to
go about it though, as I have no reason to dismiss the rationale for
using iframes in the first place - see comments delete by this patch
that make reference to style issues, deadlocks and security concerns by
not having the content contained to its own iframe.

astroidmail/astroid#720

As of WebKitGTK 2.40, enable-frame-flattening is no longer supported,
the property does nothing, resulting in all messages in the thread
viewer being cut off at around 150px, making all long messages
unreadable.

I initially had a look into seeing whether the iframe height could be
set programmatically with `webkit_dom_html_iframe_element_set_height`
from the content of the iframe via `webkit_dom_element_get_scroll_height`.
However nothing worked at page load time of an email thread, the content
scroll height remained at 150 throughout the entire
`ThreadView_on_load_changed` pass (because iframes are rendered lazily
after the main window thread has finished?  Can't think of any other
reason why this was observed). The scroll height was only found to
update after the thread had finished loading, and triggering a hide/show
toggle on each message.

Another option would be to use the JavaScriptCore API, and have all the
logic to manipulate the height of the iframe in JS. Two possible
problems with this: Firstly `enable-javascript` is explicitly disabled
in Astroid's WebKit settings; second, potentially all of the
`webextension` code may need to be rewritten in JS - given the huge
amount of deprecation warnings when building Astroid, this likely will
have to be done in anger at some point in the future anyway.

I gave up going down the path of manipulating the iframe after setting
`srcdoc`, and replaced the iframe with a div instead. CSS has been fixed
up and theme version bumped as it would be a breaking change for all
existing users that override the theme of the UI.

I can't see any concernable difference between before and after when
viewing both text/html and text/plain messages, though it is difficult
to gauge as my starting point is broken messages.

The `AstroidExtension::reload_images` code path is the least tested of
all the changes. The minimal check I did to see whether the logic is
still fine was to send myself an email with a CID attachment, and
observe it render correctly after pressing C-i in thread view.

As far as this change is concerned, this is one way to fix astroidmail#720 that
suits my use of Astroid. I'm not convinced that it is the correct way to
go about it though, as I have no reason to dismiss the rationale for
using iframes in the first place - see comments delete by this patch
that make reference to style issues, deadlocks and security concerns by
not having the content contained to its own iframe.

- partly fixes astroidmail#720
- alternative to removing iframes as in astroidmail#740 or astroidmail#732

As of WebKitGTK 2.40, enable-frame-flattening is no longer supported,
the property does nothing, resulting in all messages in the thread
viewer being cut off at around 150px, making all long messages
unreadable.

I initially had a look into seeing whether the iframe height could be
set programmatically with `webkit_dom_html_iframe_element_set_height`
from the content of the iframe via `webkit_dom_element_get_scroll_height`.
However nothing worked at page load time of an email thread, the content
scroll height remained at 150 throughout the entire
`ThreadView_on_load_changed` pass (because iframes are rendered lazily
after the main window thread has finished?  Can't think of any other
reason why this was observed). The scroll height was only found to
update after the thread had finished loading, and triggering a hide/show
toggle on each message.

Another option would be to use the JavaScriptCore API, and have all the
logic to manipulate the height of the iframe in JS. Two possible
problems with this: Firstly `enable-javascript` is explicitly disabled
in Astroid's WebKit settings; second, potentially all of the
`webextension` code may need to be rewritten in JS - given the huge
amount of deprecation warnings when building Astroid, this likely will
have to be done in anger at some point in the future anyway.

I gave up going down the path of manipulating the iframe after setting
`srcdoc`, and replaced the iframe with a div instead. CSS has been fixed
up and theme version bumped as it would be a breaking change for all
existing users that override the theme of the UI.

I can't see any concernable difference between before and after when
viewing both text/html and text/plain messages, though it is difficult
to gauge as my starting point is broken messages.

The `AstroidExtension::reload_images` code path is the least tested of
all the changes. The minimal check I did to see whether the logic is
still fine was to send myself an email with a CID attachment, and
observe it render correctly after pressing C-i in thread view.

As far as this change is concerned, this is one way to fix astroidmail#720 that
suits my use of Astroid. I'm not convinced that it is the correct way to
go about it though, as I have no reason to dismiss the rationale for
using iframes in the first place - see comments delete by this patch
that make reference to style issues, deadlocks and security concerns by
not having the content contained to its own iframe.

- partly fixes astroidmail#720
- alternative to removing iframes as in astroidmail#740 or astroidmail#732

- fixes astroidmail#720
- alternative to removing iframes as in astroidmail#740 or astroidmail#732
  or the semi-working astroidmail#743

This does not allow the document (message content) to execute
javascript, as can be verified with the following email,
which displays "no scripts" by default, but "scripts active" when js is
active.

```
Date: Tue, 1 January 1970 00:00:00 +0000
From:
Subject:
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-TUjG03Ah9OcLtWE56Ucm"

--=-TUjG03Ah9OcLtWE56Ucm
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<div id=3D"jscontent">
  no scripts
</div>

<script>
  d =3D document.getElementById('jscontent');
  d.innerHTML =3D "scripts active";
</script>

--=-TUjG03Ah9OcLtWE56Ucm
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html xmlns=3D"http://www.w3.org/1999/xhtml" lang xml:lang>
<head>
  <meta charset=3D"utf-8" />
  <meta name=3D"generator" content=3D"pandoc" />
  <meta name=3D"viewport" content=3D"width=3Ddevice-width, initial-scale=3D=
1.0, user-scalable=3Dyes" />
  <style>
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
</style>
</head>
<body>
<div id=3D"jscontent">
<p>no scripts</p>
</div>
<script>
  d =3D document.getElementById('jscontent');
  d.innerHTML =3D "scripts active";
</script>
</body>
</html>

--=-TUjG03Ah9OcLtWE56Ucm--
```

- fixes astroidmail#720
- alternative to removing iframes as in astroidmail#740 or astroidmail#732
  or the semi-working astroidmail#743

This does not allow the document (message content) to execute
javascript, as can be verified with the following email,
which displays "no scripts" by default, but "scripts active" when js is
active.

```
Date: Tue, 1 January 1970 00:00:00 +0000
From:
Subject:
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-TUjG03Ah9OcLtWE56Ucm"

--=-TUjG03Ah9OcLtWE56Ucm
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<div id=3D"jscontent">
  no scripts
</div>

<script>
  d =3D document.getElementById('jscontent');
  d.innerHTML =3D "scripts active";
</script>

--=-TUjG03Ah9OcLtWE56Ucm
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html xmlns=3D"http://www.w3.org/1999/xhtml" lang xml:lang>
<head>
  <meta charset=3D"utf-8" />
  <meta name=3D"generator" content=3D"pandoc" />
  <meta name=3D"viewport" content=3D"width=3Ddevice-width, initial-scale=3D=
1.0, user-scalable=3Dyes" />
  <style>
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
</style>
</head>
<body>
<div id=3D"jscontent">
<p>no scripts</p>
</div>
<script>
  d =3D document.getElementById('jscontent');
  d.innerHTML =3D "scripts active";
</script>
</body>
</html>

--=-TUjG03Ah9OcLtWE56Ucm--
```

- fixes astroidmail#720
- alternative to removing iframes as in astroidmail#740 or astroidmail#732
  or the semi-working astroidmail#743

This does not allow the document (message content) to execute
javascript, as can be verified with the following email,
which displays "no scripts" by default, but "scripts active" when js is
active.

```
Date: Tue, 1 January 1970 00:00:00 +0000
From:
Subject:
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-TUjG03Ah9OcLtWE56Ucm"

--=-TUjG03Ah9OcLtWE56Ucm
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<div id=3D"jscontent">
  no scripts
</div>

<script>
  d =3D document.getElementById('jscontent');
  d.innerHTML =3D "scripts active";
</script>

--=-TUjG03Ah9OcLtWE56Ucm
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html xmlns=3D"http://www.w3.org/1999/xhtml" lang xml:lang>
<head>
  <meta charset=3D"utf-8" />
  <meta name=3D"generator" content=3D"pandoc" />
  <meta name=3D"viewport" content=3D"width=3Ddevice-width, initial-scale=3D=
1.0, user-scalable=3Dyes" />
  <style>
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
</style>
</head>
<body>
<div id=3D"jscontent">
<p>no scripts</p>
</div>
<script>
  d =3D document.getElementById('jscontent');
  d.innerHTML =3D "scripts active";
</script>
</body>
</html>

--=-TUjG03Ah9OcLtWE56Ucm--
```