Prior to Aaron's fix for bug 348901, whitespace characters from the HTML source was getting exposed as part of the document content. While whitespace characters are no longer be exposed, it would seem that they are still being used when identifying the extents of a particular character. My apologies for the lengthy report. 1. Launch Accerciser and load the attached test case. 2. Within Accerciser, select a paragraph in the test case 3. Type the following in the iPython console: text=acc.queryText [[text.getText(i, i+1), text.getCharacterExtents(i, 0)] for i in range(text.characterCount)] Prior to the fix for bug 348901 (I used the 3rd August build) you'd see something like this: Paragraph 3: 2 initial spaces in HTML source. [[' ', (0, 0, 0, 0)], [' ', (0, 0, 0, 0)], ['T', (8, 192, 9, 20)], ['e', (17, 192, 9, 20)], ['s', (26, 192, 9, 20)], ['t', (35, 192, 6, 20)], ['i', (41, 192, 3, 20)], ['n', (44, 192, 10, 20)], ['g', (54, 192, 10, 20)]] Paragraph 4: 3 initial spaces in HTML source. [[' ', (0, 0, 0, 0)], [' ', (0, 0, 0, 0)], [' ', (0, 0, 0, 0)], ['T', (8, 227, 9, 19)], ['e', (17, 227, 9, 19)], ['s', (26, 227, 9, 19)], ['t', (35, 227, 6, 19)], ['i', (41, 227, 3, 19)], ['n', (44, 227, 10, 19)], ['g', (54, 227, 10, 19)]] Note that the X coordinate of each letter in paragraph 3 and paragraph 4 are the same and that the exposed spaces from the source have extents of (0, 0, 0, 0). After the fix, you'll see something like this: Paragraph 3: 2 initial spaces in HTML source. [['T', (0, 0, 0, 0)], ['e', (0, 0, 0, 0)], ['s', (0, 0, 0, 0)], ['t', (0, 0, 0, 0)], ['i', (8, 192, 9, 20)], ['n', (17, 192, 9, 20)], ['g', (26, 192, 9, 20)]] Paragraph 4: 3 initial spaces in HTML source. [['T', (0, 0, 0, 0)], ['e', (0, 0, 0, 0)], ['s', (0, 0, 0, 0)], ['t', (0, 0, 0, 0)], ['i', (0, 0, 0, 0)], ['n', (0, 0, 0, 0)], ['g', (8, 227, 9, 19)]] It seems that getCharacterExtents() is not only returning the extents of the characters in the source, but, interestingly enough, for every space we actually seem to be getting two spaces' worth of extents. We were able to "hack around" the exposed whitespace bug because we were getting valid extents for the characters. This we cannot hack around.

slight oops in the steps: text = acc.queryText() NOT text = acc.queryText

Thanks for the catch! Would a summary be that we're treating the offset you give us as an offset into the source instead of into the rendered text?

To be honest, I'm not sure. :-) If you were treating the offset we give you as an offset into the source, I would expect things to be "off" by the number of whitespace characters in the source. Instead things seem to be "off" by 2x the number of whitespace characters in the source.

What type of offset does frame take as argument? You use frame->GetPointFromOffset() with content offset in your patch. Nevertheless nsTextAccessibleWrap::GetPointFromOffse() (that calls frame->GetPointFromOffset()) is used in GetCharacterExtents() that I suppose uses rendered offset because it is a public method.

It takes content offsets. In fact, all of the layout public methods take content offsets. The only public method on nsIFrame that deals at all with rendered offset is the new GetRenderedText() method from bug 348901.

Comment on attachment 275368 [details] [diff] [review] Fix flipped logic -- pass in rendered offset to GetBoundsForString(), but convert to content offset for delaying with layout calculations ok, r=me. Though we should check another calls of nsIFrame methods.

Comment on attachment 275368 [details] [diff] [review] Fix flipped logic -- pass in rendered offset to GetBoundsForString(), but convert to content offset for delaying with layout calculations Fix for regression. Low risk. Needed for Orca screen reader support.