webkit_settings_set_enable_frame_flattening() deprecation #720

mcatanzaro · 2022-08-31T19:21:06Z

Hi, this is a heads-up that the webkit_settings_set_enable_frame_flattening() and the WebKitSettings:enable-frame-flattening property will break in WebKitGTK 2.40. You'll need to figure out how to stop using them soon. If your app breaks with this setting disabled, then you'll want to ensure updated versions of your application reach environments that you care about prior to the release of WebKitGTK 2.40.

For more information: https://bugs.webkit.org/show_bug.cgi?id=242883

Sorry for the trouble. :/

stephancb · 2023-03-23T14:33:00Z

This seems to finally have bitten me (Fedora 37, webkit2gtk4.0-devel, astroid - v0.16-2-g7c2022f0).

In thread view the overflowing parts of expanded emails are hidden (i.e. not viewable). A workaround is to copy part.scss to ~/.config/astroid/ui/ as described here. Then comment the hiding of overflowing parts like

body {
...
  /* overflow-y: hidden; */
...
}

Restart astroid. Now overflowing emails are scrollable for viewing.

kirschner · 2023-05-17T07:50:09Z

I was also effected by this. Before seeing this report, I filled a bug report for the debian package and also found a temporary work around by downgrading libwebkit.

Thanks @stephancb for the temporary fix and to @mcatanzaro for the heads-up here.

bertogg · 2023-05-17T08:58:52Z

Does that fix work fine? If so, wouldn't it make sense to create a pull request with it?

bitmeise · 2023-05-17T10:30:28Z

It actually just promotes Astroid from unusable to barely usable. The view port is still very narrow.
At least on my machine.

bertogg · 2023-05-17T10:36:41Z

I see, is there anyone with knowledge on the Astroid code that can provide a better solution?

thomas2p · 2023-05-30T08:00:02Z

@bertogg @bitmeise it works better if you also overwrite the height of the iframe containing the email body. In thread-view.css look for the iframe selector and add this rule to it: height: 70vh (Adjust the value to your liking)

Example:

iframe {
  border: none;
  width: 100%;
  height: 70vh;
  text-align: left;
  float: left;
  display: block;
}

Hoping someone will eventually find a proper fix for this :)

ibuclaw · 2023-06-04T18:00:24Z

AFAICT, the content of the iframe is set here.

astroid/src/modes/thread_view/webextension/tvextension.cc

Lines 1160 to 1195 in 7c2022f

    
           void AstroidExtension::set_iframe_src (ustring mid, ustring cid, ustring body) { 
        
             LOG (debug) << "set iframe src: " << mid << ", " << cid; 
        
             WebKitDOMDocument * d = webkit_web_page_get_dom_document (page); 
        
             GError *err; 
        
             WebKitDOMHTMLElement * body_container = WEBKIT_DOM_HTML_ELEMENT(webkit_dom_document_get_element_by_id (d, cid.c_str ())); 
        
             WebKitDOMHTMLElement * iframe = 
        
               DomUtils::select (WEBKIT_DOM_NODE(body_container), ".body_iframe"); 
        
             /* by using srcdoc we avoid creating any requests that would have to be 
        
              * allowed on the main GUI thread. even if we run this function async there 
        
              * might be other sync calls to the webextension that cause blocking since 
        
              * most webextension funcs need to run on extension GUI thread in order to 
        
              * manipulate DOM tree */ 
        
             /* according to: http://w3c.github.io/html/semantics-embedded-content.html#element-attrdef-iframe-src 
        
              * we need to escape quotation marks and amperands. it seems that by using 
        
              * this call webkit does this for us. this is critical since otherwise the 
        
              * content could break out of the iframe. */ 
        
             /* it would probably be possible to mess up the style, but it should only affect the current frame content. this would anyway be possible. */ 
        
             webkit_dom_element_set_attribute (WEBKIT_DOM_ELEMENT (iframe), "srcdoc", 
        
                 ustring::compose ( 
        
                   "<STYLE>%1</STYLE>%2", 
        
                   part_css, 
        
                   body ).c_str (), 
        
                 (err = NULL, &err)); 
        
             g_object_unref (iframe); 
        
             g_object_unref (body_container); 
        
             g_object_unref (d); 
        
           }

Based from changes in other projects - looking at Evolution specifically - the height (scrollHeight?) of the message body needs to be used to dynamically set the iframe height (plus padding).

Reading the GTK docs to get sense of how things are pieced together, it does not look good that pretty much all the C++ API has been deprecated in favour of writing everything in Javascript though. :-)

https://webkitgtk.org/reference/webkitdomgtk/2.31.91/WebKitDOMHTMLIFrameElement.html#webkit-dom-html-iframe-element-set-height

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.

astroidmail/astroid#720

jorsn · 2023-08-20T12:50:54Z

In principle, this is not really difficult to fix, if (a) one uses the scrollHeight (maybe from some other DOM library if webkit's is deprecated?) and (b) there is one function which is always executed when the view is updated. However, I didn't find that one function, and I think there are different ones depending on whether the content is HTML or plain or some other MIME. At least, my fix worked only for html messages, not for an alternative part.

Does anybody know all places at which one has to add the relevant code?

rothn · 2023-09-08T04:22:39Z

Rebasing onto https://github.com/ibuclaw/astroid/tree/remove_iframes fixes the breakage for me

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-- ```

need to figure out how to get the proper upstream fix to work

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

ibuclaw mentioned this issue Jun 6, 2023

Remove enable-frame-flattening and iframe for message body #732

Closed

kirschner mentioned this issue Jul 21, 2023

emails shown truncated with webkit 2.40.3 #735

Closed

Cynerd added a commit to Cynerd/myconfigs that referenced this issue Aug 3, 2023

astroid: temporally workaround for UI

33019d1

astroidmail/astroid#720

kirschner mentioned this issue Sep 1, 2023

Expanded mail has fixed height regardless of its content #736

Closed

rothn mentioned this issue Sep 9, 2023

Remove enable-frame-flattening and iframe for message body #740

Closed

jorsn added a commit to jorsn/astroid that referenced this issue Sep 16, 2023

set iframe size on focus using deprecated DOM access

b241d1c

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

jorsn mentioned this issue Sep 16, 2023

set iframe size on focus using deprecated DOM access #743

Closed

yzhs pushed a commit to yzhs/astroid that referenced this issue Mar 30, 2024

set iframe size on focus using deprecated DOM access

f43bb69

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

jorsn mentioned this issue May 28, 2024

set iframe height in javascript #747

Merged

jorsn closed this as completed in #747 Jun 4, 2024

Kleinjohann added a commit to Kleinjohann/dotfiles that referenced this issue Jul 17, 2024

Hacky fix for astroidmail/astroid#720

bf33a7b

need to figure out how to get the proper upstream fix to work

yzhs pushed a commit to yzhs/astroid that referenced this issue Sep 22, 2024

set iframe size on focus using deprecated DOM access

7fac889

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

webkit_settings_set_enable_frame_flattening() deprecation #720

webkit_settings_set_enable_frame_flattening() deprecation #720

mcatanzaro commented Aug 31, 2022

stephancb commented Mar 23, 2023

kirschner commented May 17, 2023

bertogg commented May 17, 2023

bitmeise commented May 17, 2023

bertogg commented May 17, 2023

thomas2p commented May 30, 2023 •

edited

Loading

ibuclaw commented Jun 4, 2023

jorsn commented Aug 20, 2023

rothn commented Sep 8, 2023

webkit_settings_set_enable_frame_flattening() deprecation #720

webkit_settings_set_enable_frame_flattening() deprecation #720

Comments

mcatanzaro commented Aug 31, 2022

stephancb commented Mar 23, 2023

kirschner commented May 17, 2023

bertogg commented May 17, 2023

bitmeise commented May 17, 2023

bertogg commented May 17, 2023

thomas2p commented May 30, 2023 • edited Loading

ibuclaw commented Jun 4, 2023

jorsn commented Aug 20, 2023

rothn commented Sep 8, 2023

thomas2p commented May 30, 2023 •

edited

Loading