UNCONFIRMED Bug 89553
[Stable] [GTK] Regression: frame-flattening broken when frame content uses CSS styles 
https://bugs.webkit.org/show_bug.cgi?id=89553
Summary [Stable] [GTK] Regression: frame-flattening broken when frame content uses CS...
Dan Vrátil
Reported 2012-06-20 01:45:15 PDT
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.
Attachments
Test case (1.49 KB, application/x-gzip)
2012-06-20 01:45 PDT, Dan Vrátil 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Xan Lopez
Comment 1 2012-09-05 10:05:05 PDT
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?
Dan Vrátil
Comment 2 2012-09-05 10:24:31 PDT
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.
Carlos Garcia Campos
Comment 3 2012-09-05 23:51:01 PDT
Added to the wiki https://trac.webkit.org/wiki/WebKitGTK/1.10.x
Adam Williamson
Comment 4 2012-09-14 12:42:42 PDT
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.
Xan Lopez
Comment 5 2012-09-14 17:18:16 PDT
(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.
Dan Vrátil
Comment 6 2012-09-16 12:37:25 PDT
(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.
Martin Robinson
Comment 7 2013-02-22 09:22:53 PST
(In reply to comment #6) We're shipping new stable candidates now. Can you confirm that the issue is gone there?
Martin Robinson
Comment 8 2013-02-22 09:23:25 PST
(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
Tomas Popela
Comment 9 2013-03-07 04:13:56 PST
No it's still not working.
Milan Crha
Comment 10 2016-06-03 05:38:32 PDT
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.
Note You need to log in before you can comment on or make changes to this bug.