370651 - Caret move events for internal page links with no text have the wrong offset (at end of parent hypertext)

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Scott Haeger]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070216 Minefield/3.0a3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070216 Minefield/3.0a3pre

Clicking on an internal link results in a focus event on the document frame with item offset=None and char offset=0.  Depending on the location of the anchor (see below), we might also get a caret event on the document frame with char offset=0 and item offset= num embed chars + 1.  

Example html markup and associated events:
<a name=#alink></a><p>some text</p>:  focus event followed by caret event
<p><a name=#alink></a>some text</p>: focus event only.

What we need is a way uniquely identify an anchors end point.

Reproducible: Always

Steps to Reproduce:
1.  click on internal link.  Setup as shown in details.
2.  observe events with respective char and item offsets
3.

Comment 1

[Scott Haeger]

Further clarification about the example html markup and associated events as seen from LSR:

<a name=#alink></a><p>some text</p>:  gives caret moved on the document frame at the focus layer
<p><a name=#alink></a>some text</p>: gives caret moved on paragraph at tier layer

Comment 2

[Aaron Leventhal]

What is the meaning of the terms "focus layer" and "tier layer"

Comment 3

[parente]

Focus and tier layer are LSR concepts. Firefox problem is that we have no idea where the in-page link is taking us because we either get just a focus on the doc frame or a focus on the doc frame plus a caret moved event in the doc frame text to one past the embed containing the descendent that is the actual location of the user's POR.

Comment 4

[Aaron Leventhal]

Attachment: Testcase

Are you getting what you need when the anchor actually has text inside of it? I think you are.

See the testcase.
Anchor #1 has text -- that one should work
Anchor #2 has no text -- that's like the broken ones you are seeing

Comment 5

[Aaron Leventhal]

Attachment: Revised testcase

This one includes
Anchor #3 - an empty anchor as a direct descendant of the doc.

Questions:
1. I'm not sure what item offset is, in the original description. Is that also internal to LSR?
2. I'm always seeing the caret moved event, even in the anchor #3 case
3. When we fire the caret at one past the embed, that is because the embed has no text, so that is where the caret actually is, I believe.
4. Are you saying we should be firing the caret event on the embed itself? It exists in the accessible tree but since it's empty the caret doesn't go in front of it.
5. Or are you saying the empty anchor should support the Text interface, and we should be firing a caret event for position 0 on it.

From what I can see, other than the issue of missing caret events (which I can't duplicate), we may already be doing the right thing.

Comment 6

[Scott Haeger]

(In reply to comment #5)
> Created an attachment (id=260943) [details]
> Revised testcase
> 
> This one includes
> Anchor #3 - an empty anchor as a direct descendant of the doc.
> 
> Questions:
> 1. I'm not sure what item offset is, in the original description. Is that also
> internal to LSR?
yes, item offset is an LSR concept.

> 2. I'm always seeing the caret moved event, even in the anchor #3 case
yes, I am also seeing the caret moved event in all cases now.

> 3. When we fire the caret at one past the embed, that is because the embed has
> no text, so that is where the caret actually is, I believe.
> 4. Are you saying we should be firing the caret event on the embed itself? It
> exists in the accessible tree but since it's empty the caret doesn't go in
> front of it.
> 5. Or are you saying the empty anchor should support the Text interface, and we
> should be firing a caret event for position 0 on it.
> 
> From what I can see, other than the issue of missing caret events (which I
> can't duplicate), we may already be doing the right thing.
> 

I'm not sure how to answer questions 4 and 5.  Below is a list of the focus and caret-moved events from the new test page.

Anchor #1
focus(0, 0, None)
	source: [ | anchor #1 has text]
	application: [application | Minefield]
focus(0, 0, None)
	source: [document frame | anchor test]
	application: [application | Minefield]
object:text-caret-moved(0, 0, None)
	source: [ | ]
	application: [application | Minefield]

Anchor#2
focus(0, 0, None)
	source: [ | anchor #2 is empty]
	application: [application | Minefield]
focus(0, 0, None)
	source: [document frame | anchor test]
	application: [application | Minefield]
object:text-caret-moved(271, 0, None)
	source: [paragraph | ]
	application: [application | Minefield]

Anchor#3
focus(0, 0, None)
	source: [ | anchor #3 is empty and a direct child of the doc]
	application: [application | Minefield]
focus(0, 0, None)
	source: [document frame | anchor test]
	application: [application | Minefield]
object:text-caret-moved(54, 0, None)
	source: [document frame | anchor test]
	application: [application | Minefield]

Here are some observations:
- I would prefer to have the caret-moved event to point to the beginning of the anchor text and not the end.  For example, the caret-moved should be object:text-caret-moved(262, 0, None) for anchor #2.

- As seen by accerciser, Each anchor has a 'ghost' accessible child that contains the anchor's text.  It is this 'ghost' that receives the focus and caret event as seen above for anchor 1 and 2.  The ghost has no role or accessible name and seems like an error.

- Are the test examples complete?  Do we need an anchor end point that is deep in the tree?

Comment 7

[Aaron Leventhal]

The ghost has a role of ROLE_LINK because it's an anchor. Links can also be end points.

Comment 8

[Aaron Leventhal]

Attachment: Anchor with text, child of document (works)

Comment 9

[Aaron Leventhal]

Attachment: Anchor with text, child of a heading (works)

Comment 10

[Aaron Leventhal]

I think the only real bug here is for anchors with no text like <a></a>. They are indeed very common.

Attached are two cases with anchors that do have text. They both fire caret move events to offset 0 inside the anchor. 

Comment 11

[Aaron Leventhal]

Attachment: Anchor without text, child of doc (broken)

Comment 12

[Aaron Leventhal]

Attachment: Anchor with no text, child of heading (broken)

Comment 13

[Aaron Leventhal]

Attachment: Fix DOMPointToOffset for node with offset 0 and no children