GNOME Bugzilla – Bug 627052
Orca shouldn't ignore of object:text-caret-moved events which immediately follow a window:activate event.
Last modified: 2010-09-20 10:57:46 UTC
From Joanie and Jose: What is happening now is that the Gedit frame is claiming focus. But the text widget which has focus is not claiming focus. If you get into the Gedit Find dialog and repeat your test, and then tab around the Find dialog, you should discover Orca speaks the items with focus -- because we're getting the expected focus: events. Likewise, I believe you'll find that you do not have to Alt+Tab out of Gedit. It should be sufficient to get into and out of Gedit's File menu. That, too, will cause Gedit to emit the correct focus: event.
Created attachment 168017 [details] [review] locusOfFocus fixed set in onCaretMoved
(In reply to comment #1) > Created an attachment (id=168017) [details] [review] > locusOfFocus fixed set in onCaretMoved Works fine! One small observation: After restart orca, the flat review is not in sync with the caret. In gedit for example if you press capslock+i, orca reads file edit .... When the caret is moved, the cynchronization is done. Great job.
I just regression tested this patch. No problems. Also, the patch is pretty conservative in its nature. Therefore, Ale, if you're comfortable with it, I say commit it. As for this: (In reply to comment #2) > After restart orca, the flat review is not in sync with the caret. In gedit for > example if you press capslock+i, orca reads file edit .... Yeah, again, if we're not told where you are, we don't know where you are. What the proposed fix here does is say, "If a frame or dialog is the locusOfFocus, odds are extremely good that we just landed in this window. Hey, look a caret-moved event in the newly-activated window! I bet the user is in this widget where the caret moved. We should tell the user where the caret moved to." <smile> The situation in flat review is similar, yet different. In both cases we don't know where you are. However, when we don't know where you are and you enter flat review, we don't get an event like a caret-moved event hinting at where you may be. Therefore, if we were to try to fix this other issue you point out, what we would have to do, as we were building up the flat review context, is examine each and every item as a candidate for being "where the user actually is." Unfortunately, a number of those widgets will claim STATE_FOCUSED even though they are not. Therefore, we'll have to add some additional guesswork into the picture. This all means a decrease in performance relative to the number of items visible in the application, for the purpose of literally trying to guess where you might be. We might not guess correctly. Plus, building up the flat review context is rather slow. Think Thunderbird. <smile> A long way of saying, 1) Not quite this bug; we should open a different bug this different problem with its different solution. 2) Is this something we really want to do? Especially given: > When the caret is moved, the cynchronization is done. Thoughts?
Pushed http://git.gnome.org/browse/orca/commit/?id=76ac3faf36c40e9acb5c7bc4e5139e33f22d89d2 I'll close this bug not the discussion :)