Project

Profile

Help

Bug #53

closed

When unread messages appear in an unselected tab, the cursor is moved ramdomly

Added by Vincent Le Goff over 7 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Category:
Accessibility
Sprint/Milestone:
% Done:

100%

Company:
-
Contact person:
-
Additional contact persons:
-

Description

If several tabs are opened, and messages are received on a tab that doesn't have the focus, the cursor of this tab seems to move randomly (or around the 100th line or so).

Actions #1

Updated by Vincent Le Goff over 7 years ago

  • Sprint/Milestone changed from 6 to 7
Actions #2

Updated by Vincent Le Goff over 7 years ago

  • Sprint/Milestone deleted (7)

Not sure where the bug originates from. It could be AccessPanel or NVDA. This needs more investigation.

Actions #3

Updated by Vincent Le Goff about 7 years ago

  • Category set to Accessibility
  • Status changed from Open to In Progress
  • Assignee set to Vincent Le Goff
  • Sprint/Milestone set to 11

It seems DotAccess has exactly the same problem, which means it's probably due to the AccessPanel. It does move the cursor itself, not just the focus, meaning it's probably screen reader independent. It would be necessary to log every single move, a possibility is that the editing_pos for the AccessPanel doesn't behave well when several AccessPanels are opened at once, which is the case both for CocoMUD and DotAccess.

Added by Vincent Le Goff about 7 years ago

Revision 3483445e | View on GitHub | diff

Fix #53: the cursor moved a bit randomly when several tabs were open

Actions #4

Updated by Vincent Le Goff about 7 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

Fixed in commit 3483445e2369e72044f7f9b76ddc649c580b3361.
This bug seemed to only apply when the rich text option was disabled. After careful debugging, it appeared that the output's editing_pos setting was correctly set. The problem seemed to be when changing tabs, not when receiving messages. Whether this is a limitation of the panel itself, forcing it to go back to the panel's GetInsertionPoint() seems to fix the bug.

Please register to edit this issue

Also available in: Atom PDF Tracking page