WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
29977
[GTK] shift+pageup/pagedown confuses textarea about which end of selection is anchored
https://bugs.webkit.org/show_bug.cgi?id=29977
Summary
[GTK] shift+pageup/pagedown confuses textarea about which end of selection is...
Dan Winship
Reported
2009-10-01 13:23:57 PDT
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.)
Attachments
Patch
(65.18 KB, patch)
2010-02-17 18:05 PST
,
Ojan Vafai
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Jens Petersen
Comment 1
2009-10-15 00:04:15 PDT
With 532.2 the behaviour seems worse: ie the original end of the selection is unarchored not the end made by PageUp/PageDown.
Eric Seidel (no email)
Comment 2
2009-11-12 13:07:50 PST
This seems related to
bug 21955
.
Ojan Vafai
Comment 3
2010-02-17 17:06:49 PST
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.
Ojan Vafai
Comment 4
2010-02-17 18:05:50 PST
Created
attachment 48954
[details]
Patch
Ojan Vafai
Comment 5
2010-02-17 18:13:48 PST
Nevermind. I misread this. This is a different bug. Doesn't happen on Windows. Sorry for the confusion.
Martin Robinson
Comment 6
2010-10-12 17:20:34 PDT
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?
Dan Winship
Comment 7
2010-10-13 05:21:20 PDT
Yes, sorry, this has been fixed for a long time. I could have sworn the bug had been closed...
Martin Robinson
Comment 8
2010-10-13 07:54:56 PDT
No problem! Thanks for the update.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug