User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050607 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.0.2) Gecko/20060502 Firefox/1.5.0.2 Open a large text file in firefox, use orca to read this file with orca flatreview mode, user has to wait very long time to hear that, this makes firefox look like hanging. Reproducible: Always Steps to Reproduce: 1. Launch orca and firefox. 2. Load a large text file, see attachment. 3. Turn on the numpad and press 7 and 9 to read this file line by line. Actual Results: User has to wait a very long time to hear that. It makes firefox look like hanging. Expected Results: It should not be so long time waiting. This bug can be found on vermillion_40/snv_39 with Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.0.2) Gecko/20060502 Firefox/1.5.0.2 only. It's not reproducible with Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9a1) Gecko/20060426 Minefield/3.0a1.

Ginn, please reassign to someone on your team as needed.

This is probably not a FF bug. LSR reads large text documents with no hang. The problem with Orca at the time of this report is probably that it is trying to synthesize speech for the one giant paragraph representing the text document all at once. Chunking is needed on the part of the AT.

> This is probably not a FF bug. LSR reads large text documents with no hang. The > problem with Orca at the time of this report is probably that it is trying to > synthesize speech for the one giant paragraph representing the text document > all at once. Chunking is needed on the part of the AT. This may be an Orca bug, but some things need clarification. There are several different ways that the user can access text with Orca. These include caret navigation, "say all", and flat review. Caret navigation relies upon the text implementation to provide reliable and predictable keyboard navigation. This is fundamentally broken in FF2 and it is a goal to see it fixed for FF3. "Say All" will autoread a document and currently chunks it line-by-line (I'm not sure Orca ever passed things in as one huge hunk of text as suggested by the previous comment). This relies on a working and reliable implementatin of getTextAtOffset as well as other things, such as getTextExtents and the FLOWS_FROM and FLOWS_TO relations. Unfortunately, the implementation of these things in FF2 has often been unreliable, but we hope to see it improved for FF3. Flat review, which is what this bug is referring to, will perform a spatial analysis of the text on the screen. It relies upon both a reliable hierarchy and getTextAtOffset/getTextExtents implementations. Since the FF2 implementations of these things has been somewhat sketchy in the past, Orca's flat review of FF2 can be somewhat sketchy. HOWEVER... There are some known limitations to the implementation of Orca's flat review when it comes to FF. As the Orca team ramps up on FF3, the team will work to both provide reliable test cases for FF3 as well as improve the flat review algorithm in Orca itself.

The performance is fine with trunk (Fx3) now. Although it has some bugs while flat reviewing, I'd like to close this one.

Will, Didn't mean to imply Orca has a problem now. I was only adding that performance may no longer be an issue and that the report might be out of date. We're using getTextAtOffset/getTextExtents/getOffsetAtPoint/getCharacterAtOffset in our document review also.