[Webkit-unassigned] [Bug 16520] [GTK] Acid2 has scrollbar; doesn't quite pass the test

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 23 02:08:01 PDT 2008


freyther at handhelds.org changed:

           What    |Removed                     |Added
                 CC|                            |freyther at handhelds.org

------- Comment #11 from freyther at handhelds.org  2008-04-23 02:08 PDT -------
(In reply to comment #10)

> Don't you think it's a bit hacky?

When I was implementing it I looked at GtkScrolledWindow and
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

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

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.

Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list