spun off bug 630001 comment #19

Ehsan, can we share code logic that is used by layout to navigate by words? a11y needs to find word start/end in the cached text at the offset.

(In reply to comment #1) > Ehsan, can we share code logic that is used by layout to navigate by words? > a11y needs to find word start/end in the cached text at the offset. It kind of depends on how you want to do this. The underlying API is nsIFrame::PeekOffset. For example, to get to the word end, you create a nsPeekOffsetStruct and use eSelectWord as the amount, eDirNext as the direction, eEndWord as word movement type, and false for visual, and you also specify the desired offsets, etc. PeekOffset gives you a result content node and offset (and a frame). If you want a higher level API, look into nsTypedSelection::Modify, although I think PeekOffset is a better option.

(In reply to comment #2) > (In reply to comment #1) > > Ehsan, can we share code logic that is used by layout to navigate by words? > > a11y needs to find word start/end in the cached text at the offset. > > It kind of depends on how you want to do this. The underlying API is > nsIFrame::PeekOffset. For example, to get to the word end, you create a > nsPeekOffsetStruct and use eSelectWord as the amount, eDirNext as the > direction, eEndWord as word movement type, and false for visual, and you also > specify the desired offsets, etc. that's how we do currently, but we need to operate on text cached on a11y side.

(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Ehsan, can we share code logic that is used by layout to navigate by words? > > > a11y needs to find word start/end in the cached text at the offset. > > > > It kind of depends on how you want to do this. The underlying API is > > nsIFrame::PeekOffset. For example, to get to the word end, you create a > > nsPeekOffsetStruct and use eSelectWord as the amount, eDirNext as the > > direction, eEndWord as word movement type, and false for visual, and you also > > specify the desired offsets, etc. > > that's how we do currently, but we need to operate on text cached on a11y side. I'm not sure what you mean. Is this information separate to the information stored in the frame tree and the content tree?

(In reply to comment #4) > I'm not sure what you mean. Is this information separate to the information > stored in the frame tree and the content tree? We get a text from nsIFrame::GetRenderedText and cache it on a11y side, so let's we have an offset and that string (cached text) and we need to find word start and word end. nsIFrame::PeekOffset can't be used for that, right?

(In reply to comment #5) > (In reply to comment #4) > > > I'm not sure what you mean. Is this information separate to the information > > stored in the frame tree and the content tree? > > We get a text from nsIFrame::GetRenderedText and cache it on a11y side, so > let's we have an offset and that string (cached text) and we need to find word > start and word end. nsIFrame::PeekOffset can't be used for that, right? No.

Ehsan, so what's the best way for us then? Obviously we want to compatible with word definition used in layout: we should report word end/start the same as user gets it by caret movement by words (ctrl+arrow key).

(In reply to comment #7) > Ehsan, so what's the best way for us then? Obviously we want to compatible with > word definition used in layout: we should report word end/start the same as > user gets it by caret movement by words (ctrl+arrow key). Well, the problem is that what we do in layout is really complicated by the fact that text can be spread over multiple frames at arbitrary points... Look at the eSelectWord here: <http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#5501>. This is where most of the top-level magic happens. This is where we handle platform specific details (such as, whether Ctrl+right should eat the space or not -- the layout.word_select.eat_space_to_next_word pref) too. The high-level algorithm is relatively simple. We iterate over the frames, and call PeekOffsetWord on them. nsTextFrame::PeekOffsetWord is a lot more complex though, especially the cluster iteration parts, which depends on the textrun code. You *really* don't want to duplicate all that code. And to make things more complicated, selecting words based on frames automatically takes care of hidden parts of a text for example (think of a display:none span in the middle of the text), and gets the word selection process closer to what the user would expect judging by what they see on the screen. I don't know how you "cache" text in a11y, but can't you just query the frame tree when you need to jump on word boundaries?

(In reply to comment #8) > I don't know how you "cache" text in a11y, but can't you just query the frame > tree when you need to jump on word boundaries? cache is result of nsIFrame::GetRenderedText. AT can call us when layout is in middle of update, it leads to wrong returned info and crashes.

(In reply to comment #8) > nsTextFrame::PeekOffsetWord is a lot more complex > though, especially the cluster iteration parts, which depends on the textrun > code. You *really* don't want to duplicate all that code. We'd need to have shared code, though it appears it's not trivial. > This is where most of the top-level magic happens. This is where we handle > platform specific details (such as, whether Ctrl+right should eat the space or > not -- the layout.word_select.eat_space_to_next_word pref) too. If this preference affect on word term definition then that's not what I look for. What is nsIWordBreaker about?

What is the reason that you have to cache frame text content? Are those frames no longer around when you need to access them? Have they changed?

(In reply to comment #11) > What is the reason that you have to cache frame text content? Are those frames > no longer around when you need to access them? Have they changed? We decided at the last work week, in a meeting with roc, that we'd need to do this. See bug 626660 for background.

(In reply to comment #12) > (In reply to comment #11) > > What is the reason that you have to cache frame text content? Are those frames > > no longer around when you need to access them? Have they changed? > > We decided at the last work week, in a meeting with roc, that we'd need to do > this. See bug 626660 for background. Maybe we could have a chat tomorrow about this?

(In reply to comment #13) > Maybe we could have a chat tomorrow about this? fine with me, I try to not fall asleep :)

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