getAbsolutePosition fails w/ Safari under three conditions when page is scrolled

[guest]

Safari 2.0.4 on a OSX 10.4.8 dojo-4.0 and nightlies (as of 17 Nov) have the problem

PROBLEM:

dojo.dom.getAbsolutePosition returns a position factoring in scroll bars twice (off by scroll.top) when dealing with <SELECT> <IMG> or anything positioned absolutely (and probably for other things as well).

TEST CASE:

Included is the test case for widget/test_Tooltip.html. I added 15-20 <br> tags so that you can scroll the page.

1. Scroll to the top and mouse over the icons. Everything works.
2. Scroll down about 20 pixels and compare the behavior of the icons to what you saw before. The buttons, folders and select box will stop working. Additionally if you mouse onto the tooltip it will disappear from the anchor or text link.

EXPLANATION:

Tooltips trap on mouseover and rely on getAbsolutePosition to tell if the mouse is over the thing that trips the tool tip or over the tooltip itself. If the getAbsolutePosition returns the wrong value, then the code thinks the mouse is not on the tooltip (off by a factor of scrollbar) and the code fails. The fix below factors out the scrollbar for these elements and the code begins to function, scrolled or unscrolled.

I don't know why these elements return the scroll position already included in the getAbsolutePosition (could it happen on other tags?). I have a fix sufficient for my needs (search for "account for document scrolling!" in html/layout.js):

	// account for document scrolling!
	if(includeScroll){
		if(	(!h.safari)||
			!(node.style.getPropertyValue("position") == "absolute"  || node.tagName == 'IMG' || node.tagName == 'SELECT' || node.tagName=='BUTTON'
    ) 
      
      )
		{
  		ret.y += scroll.top;
  		ret.x += scroll.left;
    
    }
// no safari or no wierd tag or abs position 
  		ret.y += scroll.top;
  		ret.x += scroll.left;
    
    }

}

All is well then.

[guest]

Check out #1965. I believe that patch solves this one as well. The report states that the fix is for Mozilla, but it appears sumAncestorProperties() is called in Safari as well.

[guest]

SumAncestor? may be called, but it isn't the problem in this case. I have applied the fix in 1965 to .40rc2 and the problem is still present.

There seems to be a fundamental difference in how the safari DOM handles absolutely positioned divs, buttons, and images. Text and relatively positioned divs are exempt, no matter how you scroll.

BTW: Another test case is to shrink the safari window down so it has scroll bars.

BBTW: .40rc2 still has this bug.

dojobugs[at]cpusoftware.com

[sjmiles]

Cannot reproduce in 0.9. To reopen, please supply a test case.