Draggable: Fixed positions include wrong scroll offset in Safari 4

[attaboy]

This re-opens bug #4142.

Safari 4 fixed the bug that this fix worked around, and as a result, fixed position scroll offsets are now wrong in Safari 4. (Ah, the joys of browsers.)

I have devised a simple patch which checks the Webkit version number before using the old workaround. Webkit 526 and higher is equivalent to Safari 4.

Basically, for tests like:

$.browser.safari && this.cssPosition == 'fixed'

The code would become:

$.browser.safari && $.browser.version < 526 && this.cssPosition == 'fixed'

[scott.gonzalez]

We should remove the browser check and actually do feature detection.

[joern.zaefferer]

Whats the feature here, and how can we detect it?

[paul]

needs reduced test case - not reproducable using  http://jquery-ui.googlecode.com/svn/trunk/tests/visual/draggable/draggable.scroll.html

[alexch]

That URL has two "Fixed" elements inside scrolling divs but neither one is even visible on the screen in Safari 4! No wonder you can't reproduce it! :-)

Just make a position:fixed div on a page with a bunch of other items halfway down a page, shrink the window so the scrollbar appears on the main window, scroll down a bit, then start dragging the div. You'll see it jump around spastically.

[alexch]

I patched my copy and did some DRYing out of the relevant code as well. It's much clearer now that 4 nearly-identical nested-ternary-operator statements are replaced with some function calls.

[alexch]

revised patch for draggable.js

[scott.gonzalez]

Fixed in r3778. Now with even more browser detection! :-(

[scott.gonzalez]

Replying to joern.zaefferer:

Whats the feature here, and how can we detect it?

The feature is whether or not we can determine the offset correctly for fixed position elements. You can create a fixed position element, position it, get the offset and determine if the value is correct.