Joanmarie Diggs Reporter
	Description • 17 years ago

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.

	Aaron Leventhal
	Comment 1 • 17 years ago

Joanie, I would think that this would be addressed by Surkov's fix for bug 409009. Can you try and see?

	Joanmarie Diggs Reporter
	Comment 2 • 17 years ago

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)

	Aaron Leventhal
	Comment 3 • 17 years ago

Surkov, can you look? I think the problem is that the table still has td's but the table itself is now inline.

	Aaron Leventhal
	Comment 4 • 17 years ago

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).

	Joanmarie Diggs Reporter
	Comment 5 • 17 years ago

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....

	Joanmarie Diggs Reporter
	Comment 6 • 17 years ago

I *believe* the original, inspirational page is this one:
http://www.travelineeastmidlands.org.uk/scripts/webtriplanner.dll/journeys

	Aaron Leventhal
	Comment 7 • 17 years ago

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.

	Joanmarie Diggs Reporter
	Comment 8 • 17 years ago

(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>

	Evan Yan
	Comment 9 • 17 years ago

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. 

	Joanmarie Diggs Reporter
	Comment 12 • 17 years ago

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.

	Evan Yan
	Comment 13 • 17 years ago

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?

	Ginn Chen
	Comment 14 • 17 years ago

(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.

	Ginn Chen
	Comment 15 • 17 years ago

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.

	Aaron Leventhal
	Comment 16 • 17 years ago

Since it's not really a table after all, Joanie should just get the correct results without having to change Orca.

	Evan Yan
	Comment 17 • 17 years ago

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.

	alexander :surkov (:asurkov) Assignee
	Comment 18 • 17 years ago

(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.

	Ginn Chen
	Comment 19 • 17 years ago

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

	Joanmarie Diggs Reporter
	Comment 20 • 17 years ago

> 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.

	Ginn Chen
	Comment 21 • 17 years ago

(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.

	Evan Yan
	Comment 22 • 17 years ago

(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.

	Aaron Leventhal
	Comment 23 • 17 years ago

This issue may possibly be affected by the patch for bug 404881.

	Evan Yan
	Comment 24 • 17 years ago

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.

	Evan Yan
	Comment 25 • 17 years ago

the regression seems caused by bug 404881.

	David Bolter [:davidb] (NeedInfo me for attention)
	Comment 26 • 8 years ago

AUTO-CLOSED. This bug untouched for over 2000 days. Please reopen if you can confirm the bug and help it progress.