The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
Ok. No need to change the fix as those are minor issues,
26-01-2012
If I wrote this code myself, I would structure it differently. But in this case one of my primary goals was to follow one of the existing major ports in order to simplify future changes and merges. The only port that truly supports both Windows and Mac turned out to be Chromium, so i mostly copied the relevant code from it.
If you think that trying to follow the Chromium structure is a non-goal, I will surely restructure the code and incorporate your comments.
frame->eventHandler()->scrollOverflow() is different from frame->view()->scroll() in that it scrolls the current overflow object rather than the view.
26-01-2012
In propagateScroll(), you attempt to scroll the current frame twice: first with scrollOverflow(), second with scroll() on the first loop iteration. Is this intended? (BTW the [currentFrame] variable is not much needed, you could reuse [frame]).
focusedWebCoreFrame(page) is checked three times: in keyEvent(), keyEventDefault(), and propagateScroll(). Can we check just once?
26-01-2012
The problem is the fix for RT-18534 removed the code from EditorClientJava that handles scrolling in non-editable mode:
if (!isEditable) {
frame->eventHandler()->scrollRecursively(..., ...);
}
That functionality does in fact belong to WebPage, so I am going to add it to twkProcessKeyEvent, mimicking other ports as closely as possible.