241042 - [keyboard] [table] Can't reach the caption of a table in caret browse mode

Status: NEW

(Core :: DOM: Selection, defect, P3)

Description

[howard pan]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040407
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040407

The title of a table can't be reached through keyboard.

Reproducible: Always
Steps to Reproduce:
1. Navigate to out html testing page.
    Open the file in the attachment.
2. Find the "Table test cases" area.


Actual Results:  
No way to focuse on the caption of the table.

Expected Results:  
There should be a way to focuse on the table.

Comment 1

[howard pan]

Attachment: The page to demonstrate the bug.

Comment 2

[Bogdan Stroe]

I guess you are talking about keyboard browsing, aren't you?
That's not clear from the bug sumarry.

Otherwise, the title of a table is reacheable through type as you find.

Comment 3

[Ginn Chen]

caret browsing

Comment 4

[Dilsia A. Martinez]

Jaws from Freedom Scientifics doesn't speak the menus and links on Mozilla browser

Comment 5

[Ginn Chen]

*** Bug 335625 has been marked as a duplicate of this bug. ***

Comment 6

[Bernd]

Attachment: reduced testcase

Comment 7

[Bernd]

bug 245142 is probably a dupe, marking dependent for now

Comment 8

[Bernd]

the probably root cause of this is that the outer table frame has a caption and table frame which play the roles of line 0 and line 1 for this frame but does not have a separate line iterator interface.

Comment 9

[Bernd]

Comment 8 is bogus

The problem is nsFrameIterator::GetFirstChild will never return the caption as they live on a additional childlist. So it will always return the inner table frame which  is the first child on the primary child list. Now comes the question how much special casing can we tolerate at this interface. 
The next question is when to return the caption a a first child
1. top caption
2. left caption for a ltr table
3. right caption for a rtl table

Comment 10

[Bernd]

Aaron:

How much performance loss is acceptable for this inside nsFrameIterator::GetFirstChild as we need to query for every frame if it is a outer table frame.

The other functions need the same special casing.

Should we take the risk for 3.0, is it really worth giving the number of captions on the real web?

Comment 11

[Aaron Leventhal]

As far as I can tell, it's not worth it for Firefox 3. I've not heard that this is a major problem. The one place it might be is the Orca screen reader, which relies on care browsing. However, te text of a table caption is also available through the accessibility interfaces, and can be announced as a user enters a table.

Ginn, as far as you know do we really need this for Firefox 3?

Comment 12

[Ginn Chen]

I think it's not blocking Firefox 3.

The fix needs to consider left/right arrow, up/down arrow, caption position to the table, and the direction of the table.
In Sun Mozilla 1.7, we had a hack for left/right arrow, we considered caption position, but not the direction of the table. I think it's not very helpful. 

Comment 13

[Martijn Wargers (dead)]

Still happening in current trunk build.

Comment 14

[Alin Ilea, Desktop QA]

I am able to reproduce the issue in release 92, beta 94.0b1 and the latest Nightly 95.0a1.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:hsinyi, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

table caption frames are removed from the child list of table here:
https://searchfox.org/mozilla-central/rev/152a28cc2a64a8efefba2160550e14987b943b74/layout/base/nsCSSFrameConstructor.cpp#1988-1998

Perhaps, PeekOffset does not treat this.