To Scroll or not to Scroll, that is the jQuery!

Published by: jack 2009-01-07

Jack, I have debated with myself about posting this here or somewhere else, but I think bugs is probably the best place for it. So...

It would seem that in proposing a possible solution to one problem (and having it accepted/implemented) ...
http://extjs.com/forum/showthread.php?t=5267
...regarding not being able to drag from a scrolled tree, another problem has been created...
http://extjs.com/forum/showthread.php?t=5441
...whereby comboboxes are not being positioned properly when using v1.0.1a - which has the modification for dragging in it.

It all seems to stem from the jquery dimensions plugin, which has a scroll/noscroll setting when asking for an element's offset (Ext.lib.Dom.getXY()). The default is 'scroll:true', which causes dimensions to take scrolling into account when calculating the top and left positions (the results that Ext uses), and this is what versions prior to v1.0.1a used in the jquery adaptor code.
This caused me a problem (as in thread 5267) when trying to drag tree nodes below the original scroll window, so my suggestion was to turn scroll off in the adaptor code.
Fine! I don't have any comboboxes in editable grids, and the solution works for me. But not, it would seem, for everybody. Comboboxes in scrolled editable grids are being positioned way off course due to scroll:false, and the solution (as in thread 5441) is to revert the adaptor code back to the default of scroll:true.

Announcing BeautyTips, a jQuery Tooltip Plugin | Lullabot::
This is affected by the scroll position and size of the current window, so each not to mention it is a bad practice to have style data within your javascript
http://www.lullabot.com/articles/announcing-beautytips-jquery-tooltip-pluginHOME

Giva Labs - mcDropdown jQuery Plug-in | Giva::
Options should not show up off screen where users would need to scroll to select when autocomplete list is hidden (it no longer scrolls to show the hidden list)
http://www.givainc.com/labs/mcdropdown_jquery_plugin.htmHOME

So currently you can either have comboboxes correctly positioned, OR you can have draggable scrolled tree nodes, but not both!

I have another solution that seems to solve both scenarios above, but once again I am unsure what effect it may have on any other parts of Ext, or whether the one place I have turned scroll off is sufficient.

Cold Constructs jQuery::
Heh, yeah, not gonna do that anymore. When the user hovers their mouse over one of the areas it scrolls the page in that direction.
http://coldconstructs.com/tag/jquery/HOME

In the jquery adaptor code (v1.0.1a) for Ext.lib.Dom, I changed the definition of getXY() from
getXY:function(el){
var o=jQuery(el).offset({scroll:false});
return [o.left,o.top];
}
to
getXY:function(el,noscroll){
var o=jQuery(el).offset({scroll:((noscroll)?false:true )});
return [o.left,o.top];
}

Then, in DDcore.js, in the definition of Ext.dd.DragDropMgr, I changed the try/catch statement in the getLocation() method from
try {
pos= Ext.lib.Dom.getXY(el);
} catch (e) { }
to
try {
pos= Ext.lib.Dom.getXY(el,true);
} catch (e) { }

My somewhat limited reasoning - which may well be erroneous - was that when determining whether an object can be dropped somewhere, you need to determine the coords of the visible bit of the target, not what has been scrolled out of view, and it was therefore valid to turn scroll off when fetching the coords for a drop target. But for other calls, like determining where to place an editing combobox, or the position of a tree node prior to dragging it, the scroll was left to default to true.

As with my first proposal, I do not know what effect this may have on other parts of Ext, and I do not have the time at the moment to change every example page from YUI to jQuery to test them all. I know it works for grid editing and for tree node dragging. What I could do with is for someone who has an example set that can be switched to jQuery (like the Ext site ones can) who can then test more scenarios. And I have not looked into the getX() and getY() methods which have also been set to scroll:false in v1.0.1a.

Sorry if this is a bit long-winded but I'm trying to be helpful where I can (and I feel a bit guilty that my initial solution broke other bits of Ext!).

It looks like it was fixed. If that is the case I can pull the workaround I put in SVN. Can you verify? Thanks.

Looks like I need to patch up another issue with getXY - do you have any details about relative 3 so I can patch it quick?

I've narrowed it down to the handling of scroll for the current element, in that, contrary to the description of how it handles scroll, the dimensions plugin not only applies the parent elements' scroll but also applies scroll if the current element is scrolled; whereas YUI does not.

I have raised a question on the jquery discuss site - http://www.nabble.com/Question-about-scroll-in-dimensions-plugin-tf3777343s15494.html - which has a bit more explanation, and I have put up the equivalent of the dimensions visual test page but using YUI instead ... http://www.wizzud.com/getxy/index.html ... if you are interested in seeing the differences. (The problem is the handling of Relative3; otherwise there are only minor differences for anything positioned to an element within Static2).

Sorry, that's me not being clear (again).
I've used this code...

...which removes dimensions and replaces with yui-utilities, the adapter, and ext-all (I could have cut down Ext but I couldn't be bothered to track through and find all the individual necessary components!). The adapter is only modified with inserted line-breaks so I could see the code more easily. All 3 are from v1.0.1a.
Then...
// $(id).offset(options, offset);
offsetArray = Ext.lib.Dom.getXY($(id)[0]);
offset = {top:offsetArray[1], left:offsetArray[0]};
...which replaces a call to the dimensions offset() function (which is what the jquery adapter calls when doing a Ext.lib.Dom.getXY) with a call to said Ext.lib.Dom.getXY, returning, and subsequently using, top and left.

So to answer your question, it uses the YUI adapter.

Is that with YUI's getXY or Ext's getXY in the YUI adapter? I override getXY for YUI because theirs has some issues.

Just in case anyone goes looking for it, this is just to let you know that the visual demonstration of the YUI getXY mentioned above has been removed due to lack of interest.

Since the other plugins always take scroll into account -I am wondering how they function correctly without this mod - any ideas?

Brandon has modified version 1.0b of dimensions such that the current element does not have its own scroll applied. I have checked the grid:inline editing and tree:dependency builder examples (which were the 2 that evinced the different problems I and others were having) and taking the {scroll:false} back out of the getXY (and presumably getX and getY as well) jquery adapter methods, ie reverting 1.0.1a back to 1.0.1 code, seems to work properly now (when using dimensions 1.0b, of course!).

PS. I have reinstated the YUI getXY visual test at Brandon's request, and you may be interested in it (or not) for the difference in positioning it shows between Firefox and IE/Opera (specifically, when positioning to elements within the scrollable Relative3 area) - Firefox is mis-positioned by the border of the positioned element, compared to IE/Opera which is not. Or maybe its vice versa? Whichever, they appear to differ by the amount of border(s) of one of the elements. Does it matter? Don't know.

I've made a few modifications to my version of the visual test so that it will
a) switch between dimensions and the YUI adapter
b) turn the borders of the target divs on or off
c) run or not run any minor tweaks I make to the YUI adapter while playing/testing

The main thing here is the effect of borders vs. no borders on the target (ie the element you're trying to get XY for). The YUI adapter seems to have a bit of difficulty here, in both IE and Firefox, depending on which target is chosen. I suspect that Firefox is only looking slightly better than IE because of errors cancelling themselves out.

Anyway, my findings are, as yet, inconclusive I'm afraid. It's difficult to keep track of what is being added where and when, and the only yardstick I have is Brandon's dimensions plugin - which seems to handle everything ok. I'm trying.