89553 2012-06-20 01:45:15 -0700 [Stable] [GTK] Regression: frame-flattening broken when frame content uses CSS styles 2017-03-11 10:44:41 -0800 1 1 1 Unclassified WebKit WebKitGTK 420+ Unspecified Unspecified UNCONFIRMED P2 Critical --- 0 dvratil webkit-unassigned adamw bugs-noreply bugzilla cgarcia dev+webkit mcrha mrobinson simon.fraser tpopela xan.lopez oldest_to_newest 653283 0 148523 dvratil 2012-06-20 01:45:15 -0700 Created attachment 148523 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. 712171 1 xan.lopez 2012-09-05 10:05:05 -0700 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? 712201 2 dvratil 2012-09-05 10:24:31 -0700 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. 712936 3 cgarcia 2012-09-05 23:51:01 -0700 Added to the wiki https://trac.webkit.org/wiki/WebKitGTK/1.10.x 721039 4 adamw 2012-09-14 12:42:42 -0700 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. 721270 5 xan.lopez 2012-09-14 17:18:16 -0700 (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. 721628 6 dvratil 2012-09-16 12:37:25 -0700 (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. 839650 7 mrobinson 2013-02-22 09:22:53 -0800 (In reply to comment #6) We're shipping new stable candidates now. Can you confirm that the issue is gone there? 839651 8 mrobinson 2013-02-22 09:23:25 -0800 (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 849952 9 tpopela 2013-03-07 04:13:56 -0800 No it's still not working. 1198912 10 mcrha 2016-06-03 05:38:32 -0700 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. 148523 2012-06-20 01:45:15 -0700 2012-06-20 01:45:15 -0700 Test case flattening.tar.gz application/x-gzip 1527 dvratil H4sICBmN4U8AA2ZsYXR0ZW5pbmcudGFyAO1YfU/bRhjn3/pTPGRqF7rEdgpJpBIiUcg6RAqoC0WT Jrln++LcuNjuvZCxqt99z905IU3boUm02zT/1MZn33PP+8uJKSdK0ZzlWbD1tRAi+v2ue/b2PnpW 2Op0+v1wN+ztPQu3ws5u2O9sQferabQGLRURAFulKLKU5F+ku2//P4rpXfxjzXjqy9mDy7gv/h0M 9ir+nQ7Gf6/7rLcF4YNr8hn8z+P/3XYQszyQM8/LkgTmhOV+Au3CrqCdwa/eo7flddZOinzKMmi3 OYslPhLMnExCpq5/aO/64dv7CBc0vmYKyS215/3ThtewWKt/F/uvIMPUeG+j7tfqv9Pvrvp/t7/X M/Xf6df1/03wHcsTrlMKAyzNAP/7s6F399FVbeAeH2/pnEmVmm8ey5Vn+0UTV0BElrQgmaFbnz7F l5sd77336KW6vmJpRhU8XbA8LRYtXNA4umHULGUiCs5pGrnNfe/RFY1PmcLfn6lSmJ8SiaoV7maO vxYMDyeLdN/Db+o6YjlT0HzidHhipZstxxUOTL+qREQ5XUDz5eQ0ujo5Oz6/iibnF+PRm9F4Z9+x qsgElewPuk4JTbe104JuGLagF4b2TCRZlhMeYQfMaaIiuSBlSdMleQsaKZVKFLeNFryMjg7H4xeH R6fQNMKM+6J3milkenY5HlutN5xSqb/x1dlhzqxOWvVRC4VMqYhImjr1j87PJocnZ6PXaxZscHPe quKCAl3ko+UXJ8yIWMbiMzQY5Gi13bwavTg9mUT4iN6cjIzzKrod57Qi/s06CzOjuTyFrqI5iTlt TwWZ4++qS6HrJq8vR3/H1E0LW7DSwBiLyWMcS5VZVH608cTcMhsRhizVZVQKTO4pNBtTxunzIHgs A+RHf/dnas5RLTxuTm06gxckjQyrv3BEC5DAeWMqKObaxqtjvczK1Pp3hpEnnK8iudx3dWhfBVVa 5BDuex++OG7X+r91tbXmgXvMff2/199b3f86u6b/d8Net+7/3wKD7ePzo8kvFyP4afJqPPQGJv7m QUk69AAGiilOhyc2OQaBe/PMxna7DcdMmioFNaMg1S2uYsqxUZE8td82qxekTlOa81tYFOJabkMQ tNtWjD09jOE9JAUvxHOIuab78GEQuB1vEDiVBnGR3tojpRN50KhOCJruN8wOwLgQdA6slHoOqdkF iWMBdVFYp0UuseGY2gCSspLJxGhGOQ44uJgRSTnXErQCvMBSUViGJAHlvks6L6kARhLNmYS8yIEo KETCfHiD7Z3FmqNUqvEGLSUBbGuSlIzm+M6p1CQlliPXidLSh5FiZA7Y9RKWapyeJc41qgRB6Znm pGVEU83kvEgBJy6DecGNGIpifTikOSW5ZSgTyqlg8p2mjhBnEAziIZog7w6hOiUaQnNFLaWTAilO LiYlm/twjMIsw5hjGBl67J1GDY2hJScJFcRYlDHs1NinK9uM/VAWUlNBnd9bxgWo0RxF6bllOGfA qbEaqLkHqELgPx9eFSJmlj8S3FBexc05ehDEQyg1v2E5QdofNZqJLrH8hFYCCW9c6F4RmuDQkKgu xoXoTFtrc83RvinVGUPFVwqtEsIsXIjNi00WdCtn1ugVkXUiqVSGEiPEkIfmSrCEYhQvlcmrG2zI lfMUao+GllrgL0td1iFPqyi2d9xCXhhlm6lWZZduYPSdJ4UwWeYs9E22B6WpAZf8WAumSh+i/tf6 /900ewjGa7in/4fdsHt3/3+2a/t/f7fu/98Cd/3fBB4uLl+MT46g0Q6Cq92jIDieHNvBAHt+2IGJ IDmWBCvwlhsEo7PGF+eFu7x/2v9jnWFpSKwW7LOrcbLs7evNfThZzo9qpuCNR/MUX8DdyHHCmL9S qGQGM8qyGTbhKTD1vTS1huKU7/u2apAbc4zw7qRmB41OGD5uVIcOGkSrouEkxYVIqUCCBkiRHDT8 tTtRYzgIHJtP6rD+W0aNGjVq1KhRo0aNGjVq1KhRo0aNfyv+BDcWTB4AKAAA