Peter Kümmel wrote:
Dov Feldstern wrote:
Try navigating by holding down one of the arrow keys. The cursor zooms
along (which is what we usually want), until at some point the mechanism
added here kicks in, and then the cursor suddenly stops moving. From
this point on, key press events are only handled one at a time --- in
other words, holding down the arrow key only moves one step. This
basically makes keyboard navigation within the document
unbearable-to-impossible.
Are you sure this bug is new? Or haven't you discovered it before my
patch because you have not tested the scrolling?
Yes, I'm sure. I've been testing this a lot lately, because my whole
rationale for fixing the way the cursor behaves inside RTL insets was
predicated on the assumption that the user will sometimes want to
"scroll through" an inset by holding an arrow key, without the cursor
getting stuck. With the current behavior, this is no longer an issue...
And I could not reproduce it here with any scrolling key
whether on Linux nor on Windows, so assume it is the same
bug as with the scroll scrolling.
I guess this has to do with the speed of the machine or something, but
the problem I'm seeing is definitely related to changeset 18376. Undoing
that specific changeset makes the problem disappear. Also, when the key
gets stuck, I see (many many times, as long as I hold the key down) the
debug output "key ignored".
Again, to reproduce, just hold down any of the arrow keys, and keep
holding it down. At some point it will just stop moving --- I assume
this will happen on any machine if you hold the key long enough. From
then on, anytime you hold down the key, only the single initial keypress
event will be processed.
Does it help when you wait a moment before pressing again the page-down key?
No. Although sometimes after continuing to work, then it "gets reset",
and holding the key behaves normally until it stops again. But
generally, once the mechanism kicks in, it seems to be in.
Peter
