View Full Version : [Ext 3.3] Seeking Workaround, Windows not Draggable in Scrollable Viewport in Firefox

13 May 2015, 12:35 PM
I've been dealing with this bug the last couple of days, where a modal window could not be dragged in a scrollable viewport after scrolling.

This only happens in Firefox (up to date). You can view the issue in action here:
(In Firefox, scroll to the bottom of the viewport and press the "lol" button, and try dragging the window)

It looks like it was reported as a bug here:

I dug around and found the root cause - when handling a mousedown on the window, the drag drog manager detects if the mouse event is above the target, however when calculating the targets location, it uses Ext.lib.getXY, which uses the following snippet:

scroll = fly(document).getScroll();
ret = [ROUND(b.left + scroll.left), ROUND(b.top + scroll.top)];

Here's the code in getScroll():

* Returns the current scroll position of the element.
* @return {Object} An object containing the scroll position in the format {left: (scrollLeft), top: (scrollTop)}
getScroll : function(){
var d = this.dom,
doc = document,
body = doc.body,
docElement = doc.documentElement,

if(d == doc || d == body){
if(Ext.isIE && Ext.isStrict){
l = docElement.scrollLeft;
t = docElement.scrollTop;
l = window.pageXOffset;
t = window.pageYOffset;
ret = {left: l || (body ? body.scrollLeft : 0), top: t || (body ? body.scrollTop : 0)};
ret = {left: d.scrollLeft, top: d.scrollTop};
return ret;

As you can see, if it can, it uses document.body.scrollLeft and document.body.scrollTop

The issue is, these return different values in Chrome and Firefox - in Chrome they're always 0.
The internet seems to think that Chrome's implementation is the non-standard one... And they suggest using body.documentElement.scrollTop...But the behavior is broken in Firefox and NOT Chrome...

But I find it puzzling why we are trying to add the scroll value, but it only works when the scroll value is 0?

I want to create a workaround for this, but I'm not sure what else will break; why it's adding the scroll in the first place; and why it only works when it calculates no scroll, even when the page is scrolled.

Is there an established workaround for this? Any advice?

Whatever this is, it doesn't only affect dragging and dropping. Invalid field tooltips on the windows form fields will appear floating above the window / the windows screen location projected relative to the top of the page.

14 May 2015, 1:36 PM
I have come to recognize that scrollable viewports may be unsupported, and I theorize this problem wouldn't exist within a scrollable panel within the viewport-------------- i'll see about that.