[Webkit-unassigned] [Bug 20277] implement window.scrollByPages and window.scrollByLines

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=20277


arenevier at fdn.fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #22686|0                           |1
        is obsolete|                            |
  Attachment #23055|                            |review?
               Flag|                            |




------- Comment #4 from arenevier at fdn.fr  2008-08-28 09:00 PDT -------
Created an attachment (id=23055)
 --> (https://bugs.webkit.org/attachment.cgi?id=23055&action=view)
patch v2

Thanks for you useful comments. Now, main code is in FrameView, and DOMWindow
just forwards it.

> Why is Qt different here?

because in WebCore/platform/graphics/Font.h, primaryFont method does not seem
to be defined for Qt, so I fear it won't compile on qt.
May be I misunderstood something, and primaryFont is defined otherwise, but I
did not found where.

> Should we really base the definition of a line on the default font size? Is
> there a better technique? Is this what other browsers do? How does this
> definition of a page relate to what other browsers do?

Mozilla seems to be the only implementor of scrollByLines/scrollByPages; opera
and ie do not define those methods. I tried to follow mozilla's implementation:
line height is given by platform, defaults is 12pt.

> Can we make this share code with the code that scrolls a line or a page when
> you hit the arrow keys and page up and page down keys?

I checked gtk backend, and it calls scrollBy with a fixed (40) number of pixels
when hitting arrow key; it forwards keypress event to underlying gtk widget
when hitting page down key. Windows code looks quite similar (number of pixels
is 15). So, I don't see how to share code.

Problem with current patch is that scrollByLines is not coherent with hitting
arrow key (ie: it does not scroll same number of pixels); also, scrollByPages
is not coherent with hitting page down. If that's important, may be, DOMWindow
could forward directly to platform ScrollView, and each platform would handle
it their own way.


-- 
Configure bugmail: https://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.