[Webkit-unassigned] [Bug 23556] Right-to-left pages should be scrollable to reveal left overflow
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Nov 18 06:45:52 PST 2010
https://bugs.webkit.org/show_bug.cgi?id=23556
Jeremy Moskovich <playmobil at google.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #74197|0 |1
is obsolete| |
Attachment #74233| |review?
Flag| |
--- Comment #59 from Jeremy Moskovich <playmobil at google.com> 2010-11-18 06:45:51 PST ---
Created an attachment (id=74233)
--> (https://bugs.webkit.org/attachment.cgi?id=74233&action=review)
patch
dhyatt,mitz: Could you take a look please?
Updated patch with following changes:
1)History restore now works correctly, see note below.
2) Minor cleanup of horizontal-scrollbar-in-rtl.html.
3) Added layout test to make sure no scroll events are fired on initial display.
I chatted with dhyatt a bit on irc on how the platformWidget code should update the initial scrollbar position. The logical option would be to call FrameView:: setScrollPosition(), however the only place where we know that a horizontal scrollbar has been created is in [WebDynamicScrollView updateScrollers] and calling out to FrameView from there would be a layering violation. The other problem is that FrameView:: setScrollPosition() triggers a JS scroll event, which is not something we want to do when setting the initial scrollbar position.
The patch moves the scrollers by calling [documentView scrollPoint:] and works around the problem in comment #57 by short-circuiting the notification callback if it detects that the scroller is having it's initial position set programmatically.
If you think there's a better way of doing this, I'd appreciate a suggestion for an alternate approach.
Known issues with this patch:
1) scrollbar location not updated when programmatically setting direction for platformWidget code.
2) resize test in horizontal-scrollbar-in-rtl.html fails on mac platform.
I think that neither of these are regressions from the current behavior, and if it's OK I'd like to address them in a followup patch.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list