Thanks for taking a look at this. The 'wobbling' effect can be encountered if a function repeatedly positions an element using setOffset, for example the autocomplete widget in jQuery UI.
The problem is that it is possible, given the right circumstances, for fractional values to be written to CSS -- this value is then parsed by the second call to setOffset and ommitted if parseInt is used for that purpose. The effect is that the element in question will be alternating between a position based on float and one on int. Whether or not this results in a visible bug depends on the exact numbers invovled and on the browser's sub-pixel rendering I would think. It is therefore difficult to produce a minimal example, but you can observe the behaviour I describe here:
You need to monitor the CSS top value of the (initially hidden) ui-autocomplete div.
1. Select the input field and type 'a'; ui-autocomplete is displayed using a top value of '-2.39999px'.
2. Now, clear the input field and type 'a' again; ui-autocomplete is displayed, this time using a top value of '-2px'.
You can repeat these steps indefinitely with the same behaviour.
I encountered this on a site, where the fraction in question was > 0.5 and the result was plainly visible in many browsers. I suspect it is the problem that caused these issues in jQuery UI:
If I use parseFloat in setOffset I can remove the superflous Math.round or parseInt calls in ui-position. In the case of ui-position I believe this is the best solution, because ui-position has no way of knowing what a browser will do with fractions, therefore it should not touch them either way.
Of course you're right about the radix argument; here is a commit without it: