Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behavior when moving the caret using the cursor rooting keys of a braille display via brlTTY #870

Closed
nvaccessAuto opened this issue Aug 31, 2010 · 3 comments
Assignees
Milestone

Comments

@nvaccessAuto
Copy link

Reported by LaForge on 2010-08-31 11:07
I'm using an older braille display (Baum/VARIO 40) with NVDA, which is connected via brltty 4.1-2. In a text edit, when moving the caret using the cursor rooting keys, sometimes the following happens:

  1. The caret moves to the new position at the braille display.
  2. When a character is written, it is inserted at the old position and the caret jumps back there.
  3. Pressing backspace deletes both characters left of the old and new position or those left of the old and exactly at the new position. After this, the caret is either still at the old or at the new position - this seems to differ from time to time.
  4. Pressing delete causes similar strange behavior.

This problem exists similarly in NVDA 2010.1.

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2010-08-31 11:13
Does this happen in editable text fields in specific applications or just editable text fields in general? Also, please try a main snapshot with rev 3799 or later, as I changed some of the code related to this yesterday.

@nvaccessAuto
Copy link
Author

Comment 2 by LaForge (in reply to comment 1) on 2010-08-31 16:42
Replying to jteh:

Does this happen in editable text fields in specific applications or just editable text fields in general?

It happens (or better happened) in editable text fields in general.

Also, please try a main snapshot with rev 3799 or later, as I changed some of the code related to this yesterday.

Do you have some precognition skills? With rev.3799, it works at least better. I tested with Notepad and it works fine at all. During writing this, I recognize that in Firefox 3.6.8 it updates the caret position correctly, so after pressing a CR key, all actions are done at the new position. But now, it isn't updated at the braille display until I start writing or moving. So it seems to remain at the old position which is a little confusing, but behind this it also works.

The updating problem should possibly get a separate ticket, because this also occurs in other situations.

@nvaccessAuto
Copy link
Author

Comment 3 by jteh (in reply to comment 2) on 2010-08-31 22:38
Replying to LaForge:

It happens (or better happened) in editable text fields in general.

Strange. The change I made should only really have affected IBM Lotus Symphony. Nevertheless, if it helps... :)

With rev.3799, it works at least better. I tested with Notepad and it works fine at all. During writing this, I recognize that in Firefox 3.6.8 it updates the caret position correctly, so after pressing a CR key, all actions are done at the new position. But now, it isn't updated at the braille display until I start writing or moving. So it seems to remain at the old position which is a little confusing, but behind this it also works.

It's possible that this is actually due to a bug in Firefox. I don't see this in non-Mozilla editable text fields. Do you?

closing this as fixed by 46d03db. Please reopen if the problem persists. Please file another ticket for the updating issue, providing exact steps to reproduce.
Changes:
Milestone changed from None to 2010.2
State: closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants