When selecting text with the keyboard using Shift plus a motion key, normally the behavior is that one end of the selection is anchored where you started, and the cursor moves just like it would if you weren't holding Shift down, and the other end of the selection is wherever the cursor is. However, typing Shift+PageUp or Shift+PageDown momentarily confuses WebKit so that both ends of the selection become unanchored, and if the next key is an "up" key (Up, PageUp, Home, Control+Home), then the selection will always be extended upward, and if the next key is a "down" key (Down, PageDown, End, Control+End), then the selection will be always extended downward. That is, if typing Shift+PageDown selects 10 lines downward, then you'd expect 10 Shift+Downs followed by a Shift+Up to do the same thing as 1 Shift+PageDown followed by Shift+Up. But it doesn't; the former selects 9 lines starting from the line where the cursor started, whereas the latter selects 11 lines, starting from the line above where the cursor started. (I initially thought this might be related to bug 28154, but Safari works as I would expect WebKitGTK to.)
With 532.2 the behaviour seems worse: ie the original end of the selection is unarchored not the end made by PageUp/PageDown.
This seems related to bug 21955.
This is the correct behavior on OS X. It's incorrect on other platforms. Removing the [GTK] marker since this applies to all non-Mac ports.
Created attachment 48954 [details] Patch
Nevermind. I misread this. This is a different bug. Doesn't happen on Windows. Sorry for the confusion.
Dan, do you still see this? I do not. A while ago we made some fairly major changes to the way that key events are handled in form fields. Perhaps that fixed the problem?
Yes, sorry, this has been fixed for a long time. I could have sworn the bug had been closed...
No problem! Thanks for the update.