567571 - caret-moved events missing at the end of a wrapped line of text in Thunderbird message composition

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Joanmarie Diggs]

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

[alexander :surkov (:asurkov)]

Does try build (http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-34db7d3569ea/), including patch from bug 567553, work?

Comment 2

[Fernando Herrera]

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

[Ginn Chen]

(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

[Fernando Herrera]

At the end of the line, just after the last space (or last character if words are wrapped)

Comment 5

[Fernando Herrera]

Attachment: Screnshot of ff showing the caret at the end of the line

Comment 6

[Fernando Herrera]

Attachment: Screenshot of gtk widget with caret at the end of the line

Comment 7

[Ginn Chen]

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

[alexander :surkov (:asurkov)]

(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

[alexander :surkov (:asurkov)]

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

[James Teh [:Jamie]]

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

[alexander :surkov (:asurkov)]

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

[alexander :surkov (:asurkov)]

fixed by bug 928504