You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
The caret moves to the new position at the braille display.
When a character is written, it is inserted at the old position and the caret jumps back there.
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.
Pressing delete causes similar strange behavior.
This problem exists similarly in NVDA 2010.1.
The text was updated successfully, but these errors were encountered:
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.
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.
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
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:
This problem exists similarly in NVDA 2010.1.
The text was updated successfully, but these errors were encountered: