To recreate you turn the magnifier on and try navigating with they keys through some applications which have larger widgets to focus on and you are soon likely to note that view of the focused widget can often be too far away to be in visible ranges of the magnifier zoom regions. 

Sometimes the widget remains completely out of view. Yet it is clear the tracking is active and that the view moved because a widget somewhere gained focus to prompt a visual change. 

I suspect this is happening because the focused widget needs responds to the query made for its extents with x, and y values which need to have correction applied to them before these x,y coordinates get interpreted since their interpretation is wrong otherwise. 

The API documentation does not say which part of a component it takes to be x nor y, I am assuming convention to be top left at 0, 0 at the moment which would make sense given the problem it seems to have in finding larger widgets to magnifiy 

I did a badly drawn ascii diagram to express what I think got overlooked but whatever, way round the principle of correcting the systematic error which results would be the same in any case and I think it should be straight forward to correct and get the focus tracking working properly, at last as long as my assumptions are warm. 


 Sketch: THE Desktop

(0,0)     x  (x,0)
  --------------> 
  |  *--------*
y |  |    | o || the 'o' and | | reoresebts the widget and windows respectively
  |  *--------*
  \/
  (0,y)


I reckon an evaluation of the advantages of the default focus-tracking settings needs a second look too. As the issue does seems to be worse under 'push' consider how quickly focus can be gained and how slowly it reacts on top of the fact it seems to be contributing to the negative impact skewed data being read by the magnifier seem to make on the experience of trying to key navigate with it activated.

Thanks.