Created attachment 148523 [details] Test case When frame-flattening is enabled and document in an <iframe> contains CSS styles (via <link> or <style>), the frame-flattening does not work - frame is not resized to match height of the content and no scrolling bars are displayed. In-line styles does not affect the behavior. Resizing the webview makes the frame to be resized correctly. This is a regression that must have appeared during WebKitGtk 1.9.X (I have reproduced this on 1.9.3 but haven't tried previous versions). This is not reproducible with WebKitGtk 1.8.3. See attached test-case. In frame.html there is a <style> tag in <head>. Removing (or commenting) the tag makes frame-flattening work.
Apparently this is causing serious trouble in Evolution, we should have a look at it for 3.6. I'm not sure why Evolution would want to enable flame flattening though?
We need it because we display each mail part in it's own <iframe>. This allows us to for example render plain text part and HTML part (which is a full-featued HTML document) in a single webview. We obviously want the iframes to adapt their height to height of their content so that the entire document has just a single scrollbar, so we use frame-flattening.
Added to the wiki https://trac.webkit.org/wiki/WebKitGTK/1.10.x
Just for the record, this is really making Evolution 3.6 pretty much unusable for me. As I described in a downstream bug: "1. Select an unread mail, it will be properly displayed in the preview pane: then switch to any other window. I just picked the latest unread mail in my box, alt-tabbed to this window, and saw the bug happen immediately. This is 100% reproducible for me. 2. Select a mail in the list, read it in the preview pane, hit 'up' to select the next mail up in the list, hit 'down' to go back to the mail you just read, and you'll see the bug. In fact, any time I click on any mail I've already read in my mailbox, the preview pane is broken in this way. It _only_ correctly shows mails I've never read before, and only ever once, as long as I don't alt-tab." As you can imagine, when it's this easy to reproduce the bug, it's not really practical to use Evo. It would be really nice to have it fixed soon.
(In reply to comment #2) > We need it because we display each mail part in it's own <iframe>. This allows us to for example render plain text part and HTML part (which is a full-featued HTML document) in a single webview. > > We obviously want the iframes to adapt their height to height of their content so that the entire document has just a single scrollbar, so we use frame-flattening. At risk of stating the obvious, it seems to me that it's not particularly mandatory to implement things this way. So if this go is not fixed a possible workaround would to just not use the same webview with different iframes to render the content.
(In reply to comment #5) > (In reply to comment #2) > > We need it because we display each mail part in it's own <iframe>. This allows us to for example render plain text part and HTML part (which is a full-featued HTML document) in a single webview. > > > > We obviously want the iframes to adapt their height to height of their content so that the entire document has just a single scrollbar, so we use frame-flattening. > > At risk of stating the obvious, it seems to me that it's not particularly > mandatory to implement things this way. So if this go is not fixed a possible > workaround would to just not use the same webview with different iframes to > render the content. We tried having multiple WebKitWebViews in a single GtkScrolledWindow and it does not really work well, mainly because we have to implement our own frame-flattening (or rather webview-flattening) algorithm, for instance I was unable to make the webview shrink when the content became lower then the current webview (by making the window wider for instance). Also it does not really scale well, as we could end up having a WebKitWebView inside a WebKitWebView (for instance an text/plain email with an another text/plain email as an attachment) and that has notable impact on performance mainly when scrolling (we tried that as well). Switching to multi-webview approach would also require extensive changes in our code, I doubt we would be able to do it and test it properly before freeze for 3.6 release later this month.
(In reply to comment #6) We're shipping new stable candidates now. Can you confirm that the issue is gone there?
(In reply to comment #7) > (In reply to comment #6) > > We're shipping new stable candidates now. Can you confirm that the issue is gone there? Er. And here's a link to the latest: http://webkitgtk.org/releases/webkitgtk-1.11.90.tar.xz
No it's still not working.
I guess you can close it now. I'm not able to reproduce it with the attached test case under 2.2.8, neither 2.4.11.