GNOME Bugzilla – Bug 157958
Current object from the current tab is not always reported
Last modified: 2006-02-13 17:08:00 UTC
Steps to reproduce: 1. Start Gnopernicus 2. Add to bottom panel "Email and Calendar", push button. 3. Focus the 'Email and Calendar' button. 4. Right click and chose 'Properties'. The property window opens. Actual behavior: Gnopernicus reports: 'create window <window title> create tab <tab name>'. Gnopernicus does not report the current focused object (the name text field in this case). Expected behavior: After window and tab, the current focused object should be reported (in the case that the tab is not the current focused obj). This bug is not 100% reproductible.
If I switch between tabs, the current focused obj is reported.
Created attachment 33839 [details] [review] proposed patch
please explain this patch.
Gnopernicus has few categories of events (focus tracking, wach tracking, window, mouse). Every category has an entry in a structure. When a new event is received, the old one is destroyed and the new one is put in the proper place in the structure. In this way, the structure contains only the last event for every category. Also, when an event with a higher priority is stored, events with lower priority are removed (focus events are removed by window events). When events are reported (on an idle callback), first are reported events with higher prioruty. this is done in a for intruction. for priority = higher_one to lower_one report_event_with_priority (priority) /* if any */ So, window event are reported before focus events. In case of this bug, there are 3 events involved: 2 window events and a focus event. The order is window create (for the top-level window) tab-create (for the new created tab) focus (for focused object). First event is received. After that is a pause, because the idle callback is called. The first event is reported ( ahigher priority event). During this report, the next 2 events are received (at-spi is reentrant). They will be stored in the structure. The presentation will continue with next priority, the focus event. It is presented to user, but the speech output will be interrupted by the new presented window event. receive 1st window event store it in structure remove it from structure and start to present it (*) while in (*) receive 2nd window event store it in structure receive focus event store it in structure [end first event presentation] continue the presentation with an event with a lower priority (with focus) [end all lower priority events presentation] present 2nd window event. As it can be seen, last 2 events order is reversed. My patch tries to correct this by not presenting an event for a lower priority event if in structure is a higher priority event. (it will be presented at next idle call). This way, events' order is preserved.
*** Bug 163694 has been marked as a duplicate of this bug. ***
*** Bug 163697 has been marked as a duplicate of this bug. ***
If the system is busy, couldn't this patch cause low-priority events to get held for too long and then presented (after _several_ higher-priority events) ? Wouldn't that introduce new bugs?
This patch prevents only lower-priority events to be presented before higher priority events if they are stored after (comment #4). When a higher priority event is stored, all lower-priority events are removed, so, no chance for lower-priority event to be hold (not even for one higher-priority event).
Internal ref #6232197.
Comment on attachment 33839 [details] [review] proposed patch Patch commited to head.
Reopening, as Dublin QA reports that this bug is still present after applying the patch. Following the steps in the initial description still results in no report of the currently focussed object.
In some cases, only the window event is obtained (focus event is not fired by the application). See comment #3 from bug #301077. I will investigate to see if this is the reason.
The cause of this bug is the order of events: 607: 809db50p focus: for () role text with details 0 0 608: 809dff8p object:children-changed:add for () role page tab list with details 0 0 609: 809dff8p object:children-changed:add for () role page tab list with details 0 0 As it can be seen, focus is received before adding the tab-page to page-tab-list. This bug is more reproducible on slowest machines.
Why is the 'children-changed:add' event causing the speech from the focus event to get pre-empted? That does not seem correct to me, thus maybe a gnopernicus bug.
*** This bug has been marked as a duplicate of 316296 ***
This bug should NOT have been closed as a duplicate, since that loses all the correct historical change information associated with the original bug - if it's a dup, then the patch should not have been applied to cvs, should it? If the patch was correct, then this bug should stay as a valid independent bug, and the 'description' above should be moved to the other bug. That also implies that the original description for this bug needs to be amended, since the patch doesn't fix it.
I agree this is not a dup of 316296. But solving it, this bug will be also fixed. First patch is still necessary. It fixes other issues. Even this bug is sometimes fixed by it. So, mo need to revert it (see comment #4 for details).
From conversation with Remus today - see comment #13 - the issue is that we get a focus event for an object that isn't yet realized on the screen; then later we get a children-changed:add event for that same object. Seems like the bug is that this order is wrong. How can an object that isn't yet on the screen be focused. Problem in gail?
It seems that Remus may be incorrect. While it's true that the 'focus' event may precede the 'children-changed:add" event, that's only because the 'children_changed:add" event is emitted in an idle hander; the child HAS already been added by the time the focus: event is sent. Thus I think the former explanation for the problem is not sufficient.
Remus, can you explain in detail, EXACTLY what condition is causing gnopernicus to reject this event? Since your patch (attachment 33839 [details] [review]), the pre-emptiion problem should no longer be present, so we need to know what it causing gnopernicus to fail to speak this event. Is the pre-emption logic failing, or is there something else wrong with the "focus:" event that causes it to be filtered out? We believe that the widget emitting the focus has been successfully added to the widget hierarchy by the time the event is emitted. Bill
Remus and I discussed this bug earlier today (though we didn't get into Bill's comment #20 above). Remus suggested that the necessary logic is to have Gnopernicus filter children-changed:add events and if they contain an object that just emitted a FOCUS event, to suppress speaking the children-changed:add event. This seems like an ugly hack to me. The other route is to move to the new speech/event queueing, though in that case the user will get speech in a nonsensical order for this pair of events. Remus - what is the relative priority of focus events and children-changed:add events?
I don't understand Remus' suggestion (as reported by Peter in comment #21); from what I see, the evidence is that gnopernicus is rejecting the focus: event, not that pre-emption is occurring. See Remus' patch 33839 which reportedly prevents the pre-emption issue. If pre-emption is not the problem, then what is? It appears to me that either the pre-emption patch is not working, or there is some other problem which the suggested fix in comment #21 would not be likely to fix. I agree that the suggestion in #21, if I understand Peter's restatement correctly, sounds very ugly and would almost certainly introduce regressions.
Created attachment 58936 [details] [review] proposed patch this patch prevents gnopernicus to present the creation of a tab-page if that page contains the current focus object. This because gail may report children-changed:add events after focus events in some cases.
Comment on attachment 58936 [details] [review] proposed patch patch applied to cvs head.