Bugzilla

:jfkthame, I think the issue here is that there is a very large block containing a lot of inline elements. There are block elements and hard line breaks interspersed between the inline elements. However, GetRenderedText needs to figure out whether a text node is at the start of its line, which I think means nsBlockInFlowLineIterator has to potentially crawl through all the lines in the (very large) block. Because a11y calls GetRenderedText for every text leaf, we end up with O(n^2) or worse.

I see that layout already has an optimisation for this: the line cursor. GetRenderedText even uses nsBlockFrame::AutoLineCursorSetup already. This doesn't help us, though, because AutoLineCursorSetup clears the cursor when it goes out of scope. And since we need to call this separately on each text frame, we don't benefit from that cursor as set previously.

Assuming I'm correct about any of this (I don't know this code well at all), could we create some mechanism by which a11y could tell layout it's about to do a bunch of consecutive text node retrieval? Something like AutoLineCursorSetup , but more global? AutoLineCursorSetup  would see this and not reset the cursor. I also wonder whether we could use this somehow in [mozilla::a11y::IsLocalAccAtLineStart](https://searchfox.org/mozilla-central/rev/fb319b5522a5e9fc126a9b2d2650aa49cc88e40a/accessible/base/TextLeafRange.cpp#187), though I'm not sure if nsBlockInFlowLineIterator and nsILineIterator are related and/or can be used in the same way.

:jfkthame, I think the issue here is that there is a very large block containing a lot of inline elements. There are block elements and hard line breaks interspersed between the inline elements. However, GetRenderedText needs to figure out whether a text node is at the start of its line, which I think means nsBlockInFlowLineIterator has to potentially crawl through all the lines in the (very large) block. Because a11y calls GetRenderedText for every text leaf, we end up with O(n^2) or worse.

I see that layout already has an optimisation for this: the line cursor. GetRenderedText even uses nsBlockFrame::AutoLineCursorSetup already. This doesn't help us, though, because AutoLineCursorSetup clears the cursor when it goes out of scope. And since we need to call this separately on each text frame, we don't benefit from that cursor as set previously.

Assuming I'm correct about any of this (I don't know this code well at all), could we create some mechanism by which a11y could tell layout it's about to do a bunch of consecutive text node retrieval? Something like AutoLineCursorSetup , but more global? AutoLineCursorSetup  would see this and not reset the cursor. I also wonder whether we could use this somehow in [mozilla::a11y::IsLocalAccAtLineStart](https://searchfox.org/mozilla-central/rev/fb319b5522a5e9fc126a9b2d2650aa49cc88e40a/accessible/base/TextLeafRange.cpp#187), though I'm not sure if nsBlockInFlowLineIterator and nsILineIterator are related and/or can be used in the same way. This will be important for our caching project, since with the cache enabled, I see huge bottlenecks there, too.