16520 2007-12-19 16:11:04 -0800 [GTK] Acid2 has scrollbar; doesn't quite pass the test 2009-06-12 00:03:44 -0700 1 1 1 Unclassified WebKit WebKitGTK 528+ (Nightly build) All All RESOLVED FIXED Gtk P2 Normal --- 1 alp webkit-unassigned alp jmalonzo marco.barisione mrowe webkit zecke oldest_to_newest 64767 0 alp 2007-12-19 16:11:04 -0800 Acid2 rendering works but the scrollbar is expected to be hidden since the test sets overflow: hidden -- however it's still visible in the GTK+ port. A brief look suggested the issue was not in ChromeClientGtk but rather in or around ScrollViewGtk. 64801 1 webkit 2007-12-20 05:40:04 -0800 16526 is the same thing. Happens on Mac OS X as well, not limited to just GTK. 64818 2 mrowe 2007-12-20 08:21:58 -0800 Bug 16526 is not related to this at all. 74241 3 marco.barisione 2008-03-18 05:38:02 -0700 The problem is visible when you are using real GTK scrollbars but not when you are using ScrollViewScrollbar (such as when the page with overflow:hidden is inside an iframe). Fixing the overflow:hidden bug is easy, you only have to set the GtkAdjustament so that the GtkScrolledWindow thinks that everything fits in a the page. Instead it isn't so easy to fix the problem when using overflow:scroll as you cannot easily force the scrolled window to have the scroll bars even if not needed. I can see two solutions: 1) Emit a signal from the webview to ask for a change in the scroll bar visibility policy. This sucks because you have to add code everytime you use a WebView. 2) Try to access the parent and if it's a scrolled view change the scrollbar policy. This sucks because it's just a workaround. Suggestions? 74242 4 19862 marco.barisione 2008-03-18 05:50:45 -0700 Created attachment 19862 Possible fix for the problem with overflow:hidden but not with overflow:scroll 78368 5 20715 jmalonzo 2008-04-20 22:49:32 -0700 Created attachment 20715 acid 2 and regression fix This patch makes the test pass. Also fixes a regression where new pages maintain the last page's scroll position instead of resetting the position to the top of the page. 78375 6 20715 alp 2008-04-21 00:24:08 -0700 Comment on attachment 20715 acid 2 and regression fix The frameView->setGtkAdjustments() tells the WebView to use the provided GtkScrolledWindow. Without it, WebKit falls back to its own scrollbars which isn't what we want (but they do work better). This also causes a hang when resizing http://www.google.com/ Not sure this is the right approach. 78378 7 jmalonzo 2008-04-21 01:06:04 -0700 (In reply to comment #6) > (From update of attachment 20715 [edit]) > The frameView->setGtkAdjustments() tells the WebView to use the provided > GtkScrolledWindow. Without it, WebKit falls back to its own scrollbars which > isn't what we want (but they do work better). Hi alp. So the gtk port's is different from qt or win in this regard (removing those two lines matches the qt and win's impl for example)? From what I understand that line gets the WebView's adjustment and uses that Adjustment to the new FrameView (hence when you go to a new page the scroll position doesn't move). Am I missing something? Do you have any idea where I should be looking at? > > This also causes a hang when resizing http://www.google.com/ I doesn't hang here :-\ . > > Not sure this is the right approach. Thanks anyway. Any pointers will surely help. 78386 8 marco.barisione 2008-04-21 03:37:43 -0700 Alp, the problem is that there is not way (or better, no clean way) to fully control the gtk scrollbars from inside the WebView. Do we really need to use the scroll bars created by the scrolled view? 78387 9 alp 2008-04-21 04:20:13 -0700 (In reply to comment #8) > Alp, the problem is that there is not way (or better, no clean way) to fully > control the gtk scrollbars from inside the WebView. > > Do we really need to use the scroll bars created by the scrolled view? > It's a design decision to follow GTK+ convention as closely as possible. If the widget was created within a GtkScrolledWindow we need to respect that and can deliver chrome changes by getting at the container widget and conditionally modifying the scrollbar policy in the case that it's a GtkScrolledWindow. 78433 10 marco.barisione 2008-04-21 11:35:39 -0700 (In reply to comment #9) > It's a design decision to follow GTK+ convention as closely as possible. If the > widget was created within a GtkScrolledWindow we need to respect that and can > deliver chrome changes by getting at the container widget and conditionally > modifying the scrollbar policy in the case that it's a GtkScrolledWindow. Don't you think it's a bit hacky? IMO if we implement it we should change the policy type only if it was set to GTK_POLICY_AUTOMATIC, so we don't override the explicit request to have or not to have the scrollbars. What should I do in the case of overflow:hidden? Modify the adjustament (it seems to always work well and can be used even if we are not using a scrolled window but it could break something) or use the same trick used for overflow:scroll? 78633 11 zecke 2008-04-23 02:08:01 -0700 (In reply to comment #10) > Don't you think it's a bit hacky? When I was implementing it I looked at GtkScrolledWindow and http://library.gnome.org/devel/gtk/2.6/GtkWidget.html#gtk-widget-set-scroll-adjustments. So no I don't think it is hacky but the only documented way to implement scrolling. I'm always willing to update my knowledge and change my mind. > What should I do in the case of overflow:hidden? Modify the adjustament (it > seems to always work well and can be used even if we are not using a scrolled > window but it could break something) or use the same trick used for > overflow:scroll? WebCore should handle it. In fact the only thing that changed is that the GtkAdjustmets get set at a later point in time (e.g. after a load has started). But even then updateScrollbars is called. So maybe one must force a layout again? To reiterate. It is about time to use the LayoutTests of WebKit, there are tests for parts of ACID2, e.g. I wonder if I should ask for a reduction of this bug or if we already have one in the LayoutTests. If we have a reduction and the result is different with the FrameView change and without it I can look at it. The two patches so far don't look quite right. The ScrollBar code is 'shared' with the windows port and it is unlikely we need that change but windows doesn't (only if Safari is broken as well). Not setting the GtkAdjustments is not the right thing to do for the already existing comments. 125442 12 krit 2009-06-12 00:03:44 -0700 This seems to be fixed now. Don't know what fixed it but I'm closing the bug. 19862 2008-03-18 05:50:45 -0700 2008-03-18 05:50:45 -0700 Possible fix for the problem with overflow:hidden but not with overflow:scroll hidden-scrollbars.patch text/plain 1374 marco.barisione SW5kZXg6IFdlYkNvcmUvcGxhdGZvcm0vZ3RrL1Njcm9sbFZpZXdHdGsuY3BwCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIFdlYkNvcmUvcGxhdGZvcm0vZ3RrL1Njcm9sbFZpZXdHdGsuY3BwCShyZXZpc2lvbmUgMzEx MjEpCisrKyBXZWJDb3JlL3BsYXRmb3JtL2d0ay9TY3JvbGxWaWV3R3RrLmNwcAkoY29waWEgbG9j YWxlKQpAQCAtNTg1LDcgKzU4NSwxMCBAQAogICAgIHNjcm9sbC5jbGFtcE5lZ2F0aXZlVG9aZXJv KCk7CiAKICAgICBpZiAobV9kYXRhLT5ob3Jpem9udGFsQWRqdXN0bWVudCkgewotICAgICAgICBt X2RhdGEtPmhvcml6b250YWxBZGp1c3RtZW50LT5wYWdlX3NpemUgPSB2aXNpYmxlV2lkdGgoKTsK KyAgICAgICAgaWYgKG1fZGF0YS0+aFNjcm9sbGJhck1vZGUgPT0gU2Nyb2xsYmFyQWx3YXlzT2Zm KQorICAgICAgICAgICAgbV9kYXRhLT5ob3Jpem9udGFsQWRqdXN0bWVudC0+cGFnZV9zaXplID0g Y29udGVudHNXaWR0aCgpOworICAgICAgICBlbHNlCisgICAgICAgICAgICBtX2RhdGEtPmhvcml6 b250YWxBZGp1c3RtZW50LT5wYWdlX3NpemUgPSB2aXNpYmxlV2lkdGgoKTsKICAgICAgICAgbV9k YXRhLT5ob3Jpem9udGFsQWRqdXN0bWVudC0+c3RlcF9pbmNyZW1lbnQgPSB2aXNpYmxlV2lkdGgo KSAvIDEwLjA7CiAgICAgICAgIG1fZGF0YS0+aG9yaXpvbnRhbEFkanVzdG1lbnQtPnBhZ2VfaW5j cmVtZW50ID0gdmlzaWJsZVdpZHRoKCkgKiAwLjk7CiAgICAgICAgIG1fZGF0YS0+aG9yaXpvbnRh bEFkanVzdG1lbnQtPmxvd2VyID0gMDsKQEAgLTYyMCw3ICs2MjMsMTAgQEAKICAgICB9CiAKICAg ICBpZiAobV9kYXRhLT52ZXJ0aWNhbEFkanVzdG1lbnQpIHsKLSAgICAgICAgbV9kYXRhLT52ZXJ0 aWNhbEFkanVzdG1lbnQtPnBhZ2Vfc2l6ZSA9IHZpc2libGVIZWlnaHQoKTsKKyAgICAgICAgaWYg KG1fZGF0YS0+dlNjcm9sbGJhck1vZGUgPT0gU2Nyb2xsYmFyQWx3YXlzT2ZmKQorICAgICAgICAg ICAgbV9kYXRhLT52ZXJ0aWNhbEFkanVzdG1lbnQtPnBhZ2Vfc2l6ZSA9IGNvbnRlbnRzSGVpZ2h0 KCk7CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIG1fZGF0YS0+dmVydGljYWxBZGp1c3RtZW50 LT5wYWdlX3NpemUgPSB2aXNpYmxlSGVpZ2h0KCk7CiAgICAgICAgIG1fZGF0YS0+dmVydGljYWxB ZGp1c3RtZW50LT5zdGVwX2luY3JlbWVudCA9IHZpc2libGVIZWlnaHQoKSAvIDEwLjA7CiAgICAg ICAgIG1fZGF0YS0+dmVydGljYWxBZGp1c3RtZW50LT5wYWdlX2luY3JlbWVudCA9IHZpc2libGVI ZWlnaHQoKSAqIDAuOTsKICAgICAgICAgbV9kYXRhLT52ZXJ0aWNhbEFkanVzdG1lbnQtPmxvd2Vy ID0gMDsK 20715 2008-04-20 22:49:32 -0700 2008-04-21 00:24:08 -0700 acid 2 and regression fix webkitgtk-acid2-fix.patch text/plain 1562 jmalonzo ZGlmZiAtLWdpdCBhL1dlYktpdC9ndGsvQ2hhbmdlTG9nIGIvV2ViS2l0L2d0ay9DaGFuZ2VMb2cK aW5kZXggMzI0MjE4Ni4uNjBjNDc3OSAxMDA2NDQKLS0tIGEvV2ViS2l0L2d0ay9DaGFuZ2VMb2cK KysrIGIvV2ViS2l0L2d0ay9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxNyBAQAorMjAwOC0wNC0yMCAg SmFuIE1pY2hhZWwgQWxvbnpvICA8am1hbG9uem9AdW5wbHVnZ2FibGUuY29tPgorCisgICAgICAg IFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIGh0dHA6Ly9idWdzLndlYmtp dC5vcmcvc2hvd19idWcuY2dpP2lkPTE2NTIwCisgICAgICAgIFtHVEtdIEFjaWQyIGhhcyBzY3Jv bGxiYXI7IGRvZXNuJ3QgcXVpdGUgcGFzcyB0aGUgdGVzdAorCisgICAgICAgIFRoaXMgcGF0Y2gg bWFrZXMgdGhlIHRlc3QgcGFzdC4gQWxzbyBmaXhlcyBhIHJlZ3Jlc3Npb24gd2hlcmUKKyAgICAg ICAgbmV3IHBhZ2VzIG1haW50YWluIHRoZSBsYXN0IHBhZ2UncyBzY3JvbGwgcG9zaXRpb24gaW5z dGVhZCBvZgorICAgICAgICBzdGFydGluZyBmcm9tIHRoZSB0b3Agb2YgdGhlIHBhZ2UuCisKKyAg ICAgICAgKiBXZWJDb3JlU3VwcG9ydC9GcmFtZUxvYWRlckNsaWVudEd0ay5jcHA6CisgICAgICAg IChXZWJLaXQ6OkZyYW1lTG9hZGVyQ2xpZW50Ojp0cmFuc2l0aW9uVG9Db21taXR0ZWRGb3JOZXdQ YWdlKToKKwogMjAwOC0wNC0yMCAgU2ltb24gSGF1c21hbm4gIDxoYXVzbWFubkB3ZWJraXQub3Jn PgogCiAgICAgICAgIFJldmlld2VkIGJ5IEFscCBUb2tlci4KZGlmZiAtLWdpdCBhL1dlYktpdC9n dGsvV2ViQ29yZVN1cHBvcnQvRnJhbWVMb2FkZXJDbGllbnRHdGsuY3BwIGIvV2ViS2l0L2d0ay9X ZWJDb3JlU3VwcG9ydC9GcmFtZUxvYWRlckNsaWVudEd0ay5jcHAKaW5kZXggZmM2NThlNy4uM2Ez NTdiYSAxMDA2NDQKLS0tIGEvV2ViS2l0L2d0ay9XZWJDb3JlU3VwcG9ydC9GcmFtZUxvYWRlckNs aWVudEd0ay5jcHAKKysrIGIvV2ViS2l0L2d0ay9XZWJDb3JlU3VwcG9ydC9GcmFtZUxvYWRlckNs aWVudEd0ay5jcHAKQEAgLTc1MCw4ICs3NTAsNiBAQCB2b2lkIEZyYW1lTG9hZGVyQ2xpZW50Ojp0 cmFuc2l0aW9uVG9Db21taXR0ZWRGb3JOZXdQYWdlKCkKICAgICAgICAgSW50U2l6ZSBzaXplID0g SW50U2l6ZShHVEtfV0lER0VUKGNvbnRhaW5pbmdXaW5kb3cpLT5hbGxvY2F0aW9uLndpZHRoLAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdUS19XSURHRVQoY29udGFpbmluZ1dpbmRv dyktPmFsbG9jYXRpb24uaGVpZ2h0KTsKICAgICAgICAgZnJhbWVWaWV3ID0gbmV3IEZyYW1lVmll dyhmcmFtZSwgc2l6ZSk7Ci0gICAgICAgIFdlYktpdFdlYlZpZXdQcml2YXRlKiBwcml2ID0gV0VC S0lUX1dFQl9WSUVXX0dFVF9QUklWQVRFKGNvbnRhaW5pbmdXaW5kb3cpOwotICAgICAgICBmcmFt ZVZpZXctPnNldEd0a0FkanVzdG1lbnRzKHByaXYtPmhvcml6b250YWxBZGp1c3RtZW50LCBwcml2 LT52ZXJ0aWNhbEFkanVzdG1lbnQpOwogICAgIH0gZWxzZQogICAgICAgICBmcmFtZVZpZXcgPSBu ZXcgRnJhbWVWaWV3KGZyYW1lKTsKIAo=