GNOME Bugzilla – Bug 125406
gnopernicus magnifier doesn't always follow focus
Last modified: 2004-12-22 21:47:04 UTC
gnopernicus' magnifier focus-tracking seems intermittent. Under some conditions it only sporadically follows the focus events sent to it by at-spi. At the moment I am seeing this when an 'inaccessible' application is also resident on the desktop, but it may happen in other situations. The 'inaccessible' app is not expected to focus-track, of course, but focus tracking in 'accessible' apps seems to be broken if focus moves from the inaccessible application into the accessible one. For instance, if one is running gnopernicus, gnome-cd, and an xterm, when moving from the xterm to gnome-cd via Alt-TAB, sometimes focus tracking in gnome-cd doesn't work afterwards. At other times it does; so cycling to gnome-cd several times via Alt-TAB will, eventually, cause the magnifier's focus tracking to start working again in the magnifier. (Note that I am referring to keynav-style keyboard focus tracking, not mouse following). To reproduce: Run gnome-cd, gnopernicus, and xterm. Move to gnopernicus, press arrow keys or TAB to see the magnifier track oncsreen focus. Press Alt-TAB to focus xterm; as one expects the magnifier doesn't follow focus in the xterm. Press Alt-TAB one or more times to focus gnome-cd; press arrow keys or TAB; note that sometimes the magnifier re-centers to show gnome-cd as expected, and recenters when necessary as TAB or arrow keys are pressed, but sometimes it does not.
Bill, are you sure that no part of current focused object is on magnifier. I tried to reproduce it, but with no results.
I am not able to reproduce the above scenario, please provide more information. I will explain how the magnifier focus tracking is NOW working in gnopernicus: The focus tracking is following the focus object. -If the bounding rectangle of the focus object are already magnified and totally visible then the magnified area won't move. -If the focus object is clipped to the left (so only its right part is visible) then the magnified area will move to the left, making the focused object to be inside the magnified area. -If the focus object is clipped to the right (so only its left part is visible) then the magnified area will move to the right, making the focused object to be inside the magnified area. -If the focus object is clipped on the top (so only its bottom part is visible) then the magnified area will move up, making the focused object to be inside the magnified area. -If the focus object is clipped on the bottom (so only its top part is visible) then the magnified area will move down, making the focused object to be inside the magnified area. -If the focus object is out (not visible at all) then the magnified area will move in such way that the movement will be the minimum. The algorithm described here is similar to the "push" mode of the "mouse tracking", so the focus-tracking won't be jerky. Note that there is an RFE (bug #124641) and gnopernicus will implement a centered-focus-tracking mode, too.
I understand the various tracking algorithms; however the case I am referring to is where gnopernicus does not include the currently-focussed component anywhere in the magnifier window. As I said the problem is intermittent but reproducible on my system; I can now reproduce this with ONLY gnome-cd and gnopernicus on the screen (aside from the panel of course). I have not yet seen it without gnome-cd running, so possibly there is an influence from the too-frequent window-title-changed messages from gnome-cd. I am using default gnopernicus magnification settings, i.e. 2x by 2x, vertical half-screen magnification. I am using GNOME default font size (11 point I think). To reproduce: launch gnopernicus (with brlmonitor and speech, and magnification as above). Launch gnome-cd. Place gnopernicus and gnome-cd windows in full view on the left side of the screen, as far from one another as practical. Move focus in each application to a button (for instance gnopernicus '4 - minimize' and gnome-cd 'preferences') Switch focus via Alt-TAB; magnifier will correctly re-center so that the focussed button is on-screen for each application as you switch back and forth.. Repeat several times; it doesn't have to be _too_ fast, but I find that the problem is more likely to happen if you hold the Alt key down for a long-ish time (1 second?), then press and release TAB very quickly once, releasing Alt at almost the same time. The thing that seems to make the problem more likely is a very short time between the release of TAB and the release of Alt. After 5 or 6 times switching back and forth, eventually things will get out of sync and the magnifier will stay focussed on the wrong item until another another focus event occurs due to user action. Screen resolution is 1024x768 on my system but I doubt this is of any consequence for this bug.
I was able to reproduce the bug with gnome-cd and gnome-terminal applications, inspected by simple-at program. Event flow proves that sometimes the focused object for gnome-cd and another accessible application is not well reported. For instance this is the log in case of making an ALT-TAB to the Terminal. An event from gnome-cd is reported afterwards even if the focus (graphically displayed) is on the terminal. object:visible-data-changed event received object:visible-data-changed event received object:visible-data-changed event received object:visible-data-changed event received focus: event from Terminal focus: event from Track editor object:visible-data-changed event received object:visible-data-changed event received object:visible-data-changed event received Attached to this bug is the test-program that I used and the log that I obtained. So IMHO, this is a problem in the way focus events are reported by at-spi to gnopernicus.
Created attachment 21059 [details] Test program
Created attachment 21060 [details] Log that I obtained with the test-program inspecting gnome-cd and gnome-terminal (switching between these 2 apps)
OK, so we now know that the root cause of the problem is event reordering/ordering. However we know for certain that since these events are coming from different processes, we cannot fix that issue. Therefore I think we should look into how we might work around this bug in gnopernicus (and/or at-spi?). For instance, if we detect "skew" between focus events and currently-active window, we could take appropriate action. Similarly, in the case you specifically mention above, it may be that the focus event from the cdplayer is inappropriate and can be detected and discarded either in gnopernicus or at-spi. Another possibility might be that gnopernicus could have an idle handler or timeout-handler which did a sanity check on last-focussed object versus FOCUSSED state, and correct any inconsistencies.
Would event timestamps solve this problem? If so, can we introduce such a timestamp without making an API change (I don't expect so, but I have to ask...)?
I seriously doubt that timestamps would help here. The timing/order uncertainty is not just in the delivery, it's in the initiation of notification by the application/toolkit itself. Therefore the events might well have timestamps that correspond to the order Adi reports, i.e. timestamps would also be reversed.
Event ordering is to be done in at-spi (at-spi has to provide a good event flow). Gnopernicus' job is to filter events. Bill said: "Therefore I think we should look into how we might work around this bug in gnopernicus (and/or at-spi?). For instance, if we detect "skew" between focus events and currently-active window, we could take appropriate action. Similarly, in the case you specifically mention above, it may be that the focus event from the cdplayer is inappropriate and can be detected and discarded either in gnopernicus or at-spi" Why should gnopernicus workaround?? The "skew" could be detected in at-spi, too, as Bill says at the end of the phrase. In my opinion this is an at-spi bug.
I do not actually believe that this is something we should fix in at-spi; it's in the final analysis not fixable there. at-spi cannot reorder the events without causing latency problems. Likwise, at-spi cannot suppress the events without breaking clients who expect to get the events (without depending on the order). We have always said that at-spi cannot guarantee the order of event delivery. So your assertion that at-spi must do event ordering isn't correct.
changing summary back since it describes the symptom we wish to address. We know that the underlying cause is in the event ordering, but the event ordering issue cannot be solved in the general case. Therefore we must focus on symptomatic relief.
Created attachment 21408 [details] [review] proposed patch
Bill, can you check if the patch above solves problem described by you?
Hi Remus: This patch appears to fix the problem, glad it was so simple. However if the problem appears again we should reopen the bug (since it's a race condition there's a possibility that the fix won't work in all situations). It definitely seems to help however. Thanks!
Remus, if you apply the patch I suggest that we close this bug. If the problem re-occurs we can reopen it. Thanks for the patch.
Please apply this patch and close this bug, unless there is some reason you are aware of for not applying the patch. Thanks!
Patch committed to CVS head and gnome-2-4 branch.
The patch has a serious side effect. Because many objects have no FOCUSED state when focus event is emmitted, gnopernicus behaviour is very bad. A lot of focus events are now rejected. I see 2 solutions here: 1. revert the patch, but in some cases gnopernicus will report a wrong focused object. 2. all objects should contain FOCUSED state when focus event is emmitted. Any ideeas?
all objects should have FOCUSSED state when focus is emitted. Please file bugs for cases where they do not have this state.
can you list some known cases where objects emitting 'focus' are not FOCUSSED ? thanks
I opened the bug 127400, so I close this bug.