Opened 16 years ago

Closed 15 years ago

#1947 closed defect (worksforme)

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

Reported by: guest Owned by: sjmiles
Priority: high Milestone: 0.9
Component: HTML Version: 0.4
Keywords: Cc:
Blocked By: Blocking:


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


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


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.


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(	(!h.safari)||
			!("position") == "absolute"  || node.tagName == 'IMG' || node.tagName == 'SELECT' || node.tagName=='BUTTON'
  		ret.y +=;
  		ret.x += scroll.left;
// no safari or no wierd tag or abs position 
  		ret.y +=;
  		ret.x += scroll.left;


All is well then.

Attachments (4)

test_Tooltip.html (4.8 KB) - added by guest 16 years ago.
test_Tooltip.2.html (4.8 KB) - added by guest 16 years ago.
layout.diff (660 bytes) - added by guest 16 years ago.
dojo_4_trunk.diff (687 bytes) - added by guest 16 years ago.

Download all attachments as: .zip

Change History (9)

Changed 16 years ago by guest

Attachment: test_Tooltip.html added

Changed 16 years ago by guest

Attachment: test_Tooltip.2.html added

Changed 16 years ago by guest

Attachment: layout.diff added

Changed 16 years ago by guest

Attachment: dojo_4_trunk.diff added

comment:1 Changed 16 years ago by 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.

comment:2 Changed 16 years ago by 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.


comment:3 Changed 15 years ago by dylan

Milestone: 0.9
Owner: changed from anonymous to Bryan Forbes

comment:4 Changed 15 years ago by Adam Peller

Component: GeneralHTML
Owner: changed from Bryan Forbes to sjmiles

comment:5 Changed 15 years ago by sjmiles

Resolution: worksforme
Status: newclosed

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

Note: See TracTickets for help on using tickets.