Last Comment Bug 567571 - caret-moved events missing at the end of a wrapped line of text in Thunderbird message composition
: caret-moved events missing at the end of a wrapped line of text in Thunderbir...
Status: RESOLVED FIXED
: access
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 OpenSolaris
-- normal (vote)
: mozilla27
Assigned To: alexander :surkov
:
: alexander :surkov
Mentors:
Depends on:
Blocks: orca eventa11y
  Show dependency treegraph
 
Reported: 2010-05-22 10:15 PDT by Joanmarie Diggs
Modified: 2013-10-26 18:29 PDT (History)
5 users (show)
surkov.alexander: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screnshot of ff showing the caret at the end of the line (5.72 KB, image/png)
2010-12-15 18:14 PST, Fernando Herrera
no flags Details
Screenshot of gtk widget with caret at the end of the line (35.98 KB, image/png)
2010-12-15 18:17 PST, Fernando Herrera
no flags Details

Description User image Joanmarie Diggs 2010-05-22 10:15:35 PDT
Steps to reproduce:

1. Launch Thunderbird, create a new message, typing enough text in the body of the message for the first line to wrap onto the second.

2. Launch Accerciser and enable monitoring of object;text-caret-moved events.

3. Position the caret near the end of the line and begin pressing Right Arrow until the caret moves to the end of the line and then to the beginning of the next line.

Expected results: A caret-moved event would be present each time the caret moves.

Actual results: There is no caret-moved event when the caret moves from its position at the end of the first line to the beginning of the second line.

Impact: The user who is blind arrows from the end of the first line to the beginning of the second line, but ATs are not notified and thus present nothing to the user in response.
Comment 1 User image alexander :surkov 2010-05-22 20:57:40 PDT
Does try build (http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/surkov.alexander@gmail.com-34db7d3569ea/), including patch from bug 567553, work?
Comment 2 User image Fernando Herrera 2010-12-15 18:03:51 PST
The problem here is that firefox allows caret to be positioned after the last character of a line (usually space, or a regular character when long words are wrapped), so the next "right arrow" movement, will show the caret at the beginning of the next line but that is still in the same logical offset (after the last space, or the last character).

gtk or other toolkits does not allow setting the caret after the last space/character of a line.

So to fix this bug, we would need to change caret behaviour on ff. A workaround would be to fire a caret moved event with the same offset, but that could be more confusing.
Comment 3 User image Ginn Chen 2010-12-15 18:10:22 PST
(In reply to comment #2)
> gtk or other toolkits does not allow setting the caret after the last
> space/character of a line.

so, if I press End (or whatever shortcut for end of line), where would the caret be displayed?
Comment 4 User image Fernando Herrera 2010-12-15 18:13:32 PST
At the end of the line, just after the last space (or last character if words are wrapped)
Comment 5 User image Fernando Herrera 2010-12-15 18:14:21 PST
Created attachment 497985 [details]
Screnshot of ff showing the caret at the end of the line
Comment 6 User image Fernando Herrera 2010-12-15 18:17:22 PST
Created attachment 497986 [details]
Screenshot of gtk widget with caret at the end of the line
Comment 7 User image Ginn Chen 2010-12-15 18:21:14 PST
Thanks, I understand now.

I think Gecko is doing something different here.
It's reasonable to fix Gecko. But it may be difficult.
Comment 8 User image alexander :surkov 2010-12-15 19:45:33 PST
(In reply to comment #2)

> So to fix this bug, we would need to change caret behaviour on ff. A workaround
> would be to fire a caret moved event with the same offset, but that could be
> more confusing.

or we could expose \n

(In reply to comment #7)
> I think Gecko is doing something different here.
> It's reasonable to fix Gecko. But it may be difficult.

They said it's not difficult but it's not likely be a part of Firefox 4.
Comment 9 User image alexander :surkov 2013-10-09 10:42:13 PDT
Jamie, what do you think if Firefox would do what Gtk does? That would get rid of the wrapped line offset problem. Btw, IE and Chrome don't allow caret at the end of wrapped line as well.
Comment 10 User image James Teh [:Jamie] 2013-10-09 15:12:34 PDT
I don't understand where you're suggesting the caret would be positioned when you press end. In most toolkits I've seen, the caret is still placed at the end of the line, which is what Gecko already does. The only difference with Gecko is that you can right/left arrow to that position. However, even if you change Gecko so left/right arrow can't get there, pressing end still needs to fire a caret event and that still raises the question of what offset should be reported. This issue exists in most toolkits I know of.
Comment 11 User image alexander :surkov 2013-10-10 05:37:28 PDT
Ok, got it. I don't have HOME/END key on my mac keyboard so I tried left/right arrows under different browsers. But if END on most toolkit moves the caret after last character then I don't see a huge difference if left/right behavior was copied.
Comment 12 User image alexander :surkov 2013-10-26 18:29:48 PDT
fixed by bug 928504

Note You need to log in before you can comment on or make changes to this bug.