The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla27

Status

()

Core
Disability Access APIs
RESOLVED FIXED
7 years ago
3 years ago

People

(Reporter: Joanmarie Diggs, Assigned: surkov)

Tracking

(Blocks: 2 bugs, {access})

Trunk
mozilla27
x86
OpenSolaris
access
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
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.
(Assignee)

Updated

7 years ago
Blocks: 472809
(Assignee)

Comment 1

7 years ago
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

6 years ago
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

6 years ago
(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

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

Comment 5

6 years ago
Created attachment 497985 [details]
Screnshot of ff showing the caret at the end of the line

Comment 6

6 years ago
Created attachment 497986 [details]
Screenshot of gtk widget with caret at the end of the line

Comment 7

6 years ago
Thanks, I understand now.

I think Gecko is doing something different here.
It's reasonable to fix Gecko. But it may be difficult.
(Assignee)

Comment 8

6 years ago
(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.
(Assignee)

Comment 9

4 years ago
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.
Flags: needinfo?(jamie)

Comment 10

4 years ago
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.
Flags: needinfo?(jamie)
(Assignee)

Comment 11

4 years ago
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.
(Assignee)

Comment 12

3 years ago
fixed by bug 928504
Assignee: nobody → surkov.alexander
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
You need to log in before you can comment on or make changes to this bug.