Closed Bug 409497 Opened 17 years ago Closed 8 years ago

The display:inline style interferes with getTextAtOffset()

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: jdiggs, Assigned: surkov)

References

(Blocks 2 open bugs)

Details

(Keywords: access, Whiteboard: [auto-closed:inactivity])

Attachments

(3 files, 1 obsolete file)

Attached file test case
Steps to reproduce:

1. Load the attached test case.
2. In Accerciser, select the first section in the form.
3. In Accerciser's iPython Console type:

   text = acc.queryText()
   text.getTextAtOffset(0, TEXT_BOUNDARY_LINE_START)

Expected results: The entire line of text (and corresponding offsets) would be returned.

Actual results: Only the contents from the first table cell (and its corresponding offsets) are returned.

It seems that adding the display:inline style to a table causes its contents to not be exposed as a table.  (Compare the first line with the second:  The only difference is the display:inline style being applied to the first line and not the second).

If you compare the first line with the third in Accerciser, you'll notice they share the same accessible structure.  However, if you perform step three above using the third section, you'll get the full line contents as expected.

I'm requesting that this be considered for inclusion among the Firefox 3 accessibility commitments.
Whiteboard: orca:urgent
Assignee: aaronleventhal → surkov.alexander
Joanie, I would think that this would be addressed by Surkov's fix for bug 409009. Can you try and see?
Just tried it with the current trunk.  It doesn't seem to be fixed.

~~~~~~~~~~ First Section ~~~~~~~~~~
In [1]: text = acc.queryText()
In [2]: text.getText(0, -1)
Out[2]: 'Foo:\xef\xbf\xbcMore text '
In [3]: text.getTextAtOffset(0, TEXT_BOUNDARY_LINE_START)
Out[3]: ('Foo:', 0, 4)

~~~~~~~~~~ Third Section ~~~~~~~~~~
In [4]: text = acc.queryText()
In [5]: text.getText(0, -1)
Out[5]: 'Foo: \xef\xbf\xbc More text '
In [6]: text.getTextAtOffset(0, TEXT_BOUNDARY_LINE_START)
Out[6]: ('Foo: \xef\xbf\xbc More text ', 0, 17)
Surkov, can you look? I think the problem is that the table still has td's but the table itself is now inline.
Joanie, I think it's not display: inline but the particular combination of markup here. Is this on a popular site? It looks like a bit of an edge case to me. (Not that we shouldn't fix it, but I don't see it as urgent).
So the first lesson I learned (from the 411.com Pizza Hut bug) was always make a stand-alone test case because you never know when a site might change.

What I have learned today is to always add the original URL upon which the stand-alone test case is based because my mind is like a .... what's that thing called.... the thing that water pours out of.... What were we talking about? ;-)

Long way of saying, no, I'm afraid I can no longer recall what the original site is.  (Sorry!!) Only that a user undoubtedly reported it because I can't make stuff like these test cases up. :-)  I'll see if I can narrow it down based on the date and bugs I was working on around the same time, etc.  

Hopefully it's not too popular a site or too popular a way to mark up a document....
I *believe* the original, inspirational page is this one:
http://www.travelineeastmidlands.org.uk/scripts/webtriplanner.dll/journeys
It's really weird markup and looks like an authoring mistake. I think we should deal with it but I wouldn't call it urgent.
(In reply to comment #4)
> me. (Not that we shouldn't fix it, but I don't see it as urgent).

(In reply to comment #7)
> It's really weird markup and looks like an authoring mistake. I think we should
> deal with it but I wouldn't call it urgent.

So Aaron, would you call it urgent.... or not? ;-) ;-) ;-) ;-) ;-)

I'll admit that "urgent" is in the eye of the beholder.  From your perspective, this is an oddball case -- an authoring mistake even.  Fair enough.  My perspective is based on the fact that we've just moved Orca away from its slow character-by-character line construction to a *very* heavy reliance upon getTextAtOffset().  To me, *any* instance of getTextAtOffset() not doing the right thing is "urgent." :-)  After all, how can we predict what sort of bizarre markup we'll get? <shrugs>
The texts in the inline table are actually in different table cells. That's why text.getTextAtOffset(0, TEXT_BOUNDARY_LINE_START) only returns "Foo: ", that's all the text in the table cell.

If you press HOME/END when caret is in text "Foo: ", you'll see the caret just goes to the begin and end of "Foo: ".

And try resizing the browser to wrap "More text", you can see the difference as well. 
Attached image screenshot of wrapping the text (obsolete) —
Attachment #298440 - Attachment is obsolete: true
Right, but looking at the hierarchy in Accerciser, the first and third sections seem the same.  Looking at the results from getTextAtOffset(), they are different.  See comment #2.

How do I know when I've gotten all the text?  How do I know when I need to suspect I'm not getting all of the text?  That's what I'm struggling with.
I don't quite know how Orca works, but can't you get all the text by text.getText(0,-1)? Or check the offset returned from getTextAtOffset, to see whether it reaches the end of the hypertext?
(In reply to comment #12)
> Right, but looking at the hierarchy in Accerciser, the first and third sections
> seem the same.  Looking at the results from getTextAtOffset(), they are
> different.  See comment #2.

I know they're same in Accerciser.
Also the hierarchy is same no matter the text wraps or not.

You don't expect
text.getTextAtOffset(0, TEXT_BOUNDARY_LINE_START)
give you the same result for wrapped text and text not wrapped, do you?

If Orca wants to read the text line by line, you can do it in this way.
First, get all the text by getText(0,-1)
check all the embed object, you should avoid to call getTextAtOffset for embed object.
Then do text.getTextAtOffset(0, TEXT_BOUNDARY_LINE_START)
it returns ('Foo:', 0, 4)
Offset 4 is an embed object, you should do getText/getTextOffset for the child node instead.
do text.getTextAtOffset(5, TEXT_BOUNDARY_LINE_START)
It returns ('More text', 5, 14)

display:inline makes the atk hierarchy look like the table doesn't exist,
it doesn't mean every AT_SPI API will return exactly the same result comparing to the no table version.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Correction:
If the embed object is a hyperlink,
it should be safe to call text.getTextAtOffset(x, TEXT_BOUNDARY_LINE_START).
If the embed object is a form control,
text.getTextAtOffset may gives unexpected result.
Since it's not really a table after all, Joanie should just get the correct results without having to change Orca.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I think from layout's perspective, it is still a table. The layout's behavior when user press HOME/END or resize window to wrap the text shows that, as comment #9 suggests.
(In reply to comment #17)
> I think from layout's perspective, it is still a table. The layout's behavior
> when user press HOME/END or resize window to wrap the text shows that, as
> comment #9 suggests.
> 

the problem is there is no table frame afaik and therefore our table interface can't work. So I can't see how we can expose this as a table.
Aaron,

Although it's not a real table, I don't think we have to expose all the texts as one line.
Orca is not supposed to change for this bug, Orca should be able to deal with it, otherwise it will fail for soft wrapping texts.

surkov,

I put the cursor at end of "More text" in first line.
Here's what I got in dbx.

(dbx) print this->GetParent()->GetParent()->GetParent()->GetParent()->GetParent()->GetParent()->GetParent()->GetParent()
(class nsBlockFrame *) ((class nsInlineFrame *) ((class nsTableOuterFrame *) ((class nsTableFrame *) ((class nsTableRowGroupFrame *) ((class nsTableRowFrame *) ((class nsTableCellFrame *) ((class nsBlockFrame *) ((class nsTextFrame *) this)->GetParent())->GetParent())->GetParent())->GetParent())->GetParent())->GetParent())->GetParent())->GetParent() = 0x8ebf630

> Orca is not supposed to change for this bug, Orca should be able to deal with
> it, otherwise it will fail for soft wrapping texts.

We don't fail for soft wrapping texts. :-)  Granted I'm still working on some bugs, but generally speaking, given a section (and pretty much most objects which aren't table cells) -- we do a getTextAtOffset() and we're given the line we asked for as expected. Unfortunately, given the first section in this bug, that does not work. :-(

> the problem is there is no table frame afaik and therefore our table interface
> can't work. So I can't see how we can expose this as a table.

To be honest, I'd prefer that you didn't. ;-)  I like how it's exposed now.  I like the results we get from getText(0, -1).  It would be nice if getTextAtOffset() returned the same result for the first section and the third section.
(In reply to comment #20)
> We don't fail for soft wrapping texts. :-)  Granted I'm still working on some
> bugs, but generally speaking, given a section (and pretty much most objects
> which aren't table cells) -- we do a getTextAtOffset() and we're given the line
> we asked for as expected. Unfortunately, given the first section in this bug,
> that does not work. :-(

What's the different between cells of a display:inline table and soft wrapping texts,
from Orca's point of view?
 
> > the problem is there is no table frame afaik and therefore our table interface
> > can't work. So I can't see how we can expose this as a table.
> 
> To be honest, I'd prefer that you didn't. ;-)  I like how it's exposed now.  I
> like the results we get from getText(0, -1).  It would be nice if
> getTextAtOffset() returned the same result for the first section and the third
> section.

I think if we want solve this issue, perhaps the only way is to expose it as a real table accessible.
(In reply to comment #20)
> It would be nice if
> getTextAtOffset() returned the same result for the first section and the third
> section.
> 
What's the expected result to be returned by getTextAtOffset(0, LINE_START) under the case of my screenshot (resizing window to wrap "More text")?

Returning 'Foo:\xef\xbf\xbcMore' doesn't make sense to me.
This issue may possibly be affected by the patch for bug 404881.
The first section is now exposed as follows:

hypertext
-- table cell
-- table cell
-- table cell

Table cell accessibles is children of a hypertext accessible, instead of a table accessible.
the regression seems caused by bug 404881.
Blocks: texta11y
AUTO-CLOSED. This bug untouched for over 2000 days. Please reopen if you can confirm the bug and help it progress.
Status: REOPENED → RESOLVED
Closed: 17 years ago8 years ago
Resolution: --- → INCOMPLETE
Whiteboard: orca:urgent → [auto-closed:inactivity]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: