343423 - offsetParent bug related to scroll in div-tag

Status: UNCONFIRMED

(Core :: DOM: CSS Object Model, defect, P5)

Description

[Terje Rosenlund]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

FF skips DIV-tags when assigning backwards obj.offsetParent.offsetParent... chain 
Causes miss-calculated possitiones for elements contained in scrolling div-tags

Reproducible: Always

Steps to Reproduce:
1. Check out example app.

Scroll the div tag an repeate check to se the bug


Actual Results:  
Possitones are miss-calculated if the div-tag is in a scrolled possition


Scroll-offsets are recorded on the scrolling element (DIV) itself 
Skipping DIV-tags defeates the purpose of the offsetParent-chain

(.. may explane bug-id 330317, 340571, 337828 and 331338)

Comment 1

[Anne (:annevk)]

This looks invalid. Emulating hasLayout from IE for offsetParent is insane.

Comment 2

[Terje Rosenlund]

(In reply to comment #1)
> This looks invalid. Emulating hasLayout from IE for offsetParent is insane.

Not shore if you comment my bug-report or some of the other cases

The fix for the bug in question is not to skip DIV-tags when assigning offsetParents (.. or is that to 'Emulating hasLayout from IE' ?)

To visualice:

The script containes function MarkPos()

- Run 'Expression to evaluate': d = TrackPos("track_0"); MarkPos(d, 'pink');
- Remove the marker by pressing 'x'
- Scroll the div and press 'Evaluate'

The marker is still in same possition (ok in IE7)

Comment 3

[Anne (:annevk)]

(In reply to comment #2)
> The fix for the bug in question is not to skip DIV-tags when assigning
> offsetParents (.. or is that to 'Emulating hasLayout from IE' ?)

Yes. Except that you want Mozilla to be different in yet another way; IE often does skip DIV elements. For example, when they don't have any special style set. The proposed specification for implementing offset* is here:

  http://dump.testsuite.org/2006/dom/style/offset/spec

Comment 4

[Terje Rosenlund]

(In reply to comment #3)
> (In reply to comment #2)
> > The fix for the bug in question is not to skip DIV-tags when assigning
> > offsetParents (.. or is that to 'Emulating hasLayout from IE' ?)
> 
> Yes. Except that you want Mozilla to be different in yet another way; IE often
> does skip DIV elements. For example, when they don't have any special style
> set. The proposed specification for implementing offset* is here:
> 
>   http://dump.testsuite.org/2006/dom/style/offset/spec
> 
Your draft states:

'If node A implements the HTMLHtmlElement .... its offsetParent attribute must be null.'

I guess that means DIV and all other scrolling objects (?)

Won't that imply that the absolute possition for scrolled objects can't be calculate based on the offsetParent chain?

The workaround that ensures correct calculation of absolute possition is quite simpel but I don't know enough about the class hierarchi to se the implicationes for your draft :)

if (is_netscape() && obj.offsetParent && obj.offsetParent.parentNode.nodeName=='DIV')

.. use scroll-values from obj.offsetParent.parentNode

else

.. use scroll-values from obj

New workaround test-app . posted at: http://nettkompetanse.no/Mozilla/offsetParent-bug-fix/offsetParent-bug.html

- Press 'Track possition for track_0' 
- Scroll the DIV
- Press 'Evaluate'

Comment 5

[Terje Rosenlund]

> Emulating hasLayout from IE for offsetParent is insane.

Seems to me that hasLayout simply is the result of: 

o = DOM:Element;
s = o.style;
o.hasLayout = (s.height || s.width || s.position=='absolute' || s.display=='inline-block' || s.writingMode=='tb-rl' || s.zoom) ? true : false;

- Quite sane and easy to implement in Mozilla I would think?

The question is whether this information is needed (can't see any use for it)

> IE often does skip DIV elements

DIV-tags ain't skipped in IE7 when hasLayout==false

- Do they skip elements at all anymore?

Mozilla always skips DIV-tags from the offsetParent-chain as far as I can see

- Are other elements also skipped?

When Mozilla skips a DIV-tag its offset-values are moved to the content-objects offset -top and -left (mangled), except borders which are ignored (BUG)
The DIV-tags scrollX and scrollY are not moved eather (BUG)
Moving scroll-values would give eg. a TABLE with scrollX and/or scrollY which looks silly but is the only way not to lose skipped DIV-tags scroll-data

I have written a web-application where I need to know exactly where to place dynamic content
In order to achieve this for Mozilla I had to write a function which in effect eliminates all skipping and mangling 
The offsetParent-chain for Mozilla and IE7 are now equal and in a form which makes it very easy to calculate outer, inner and visible area for any object on screen

- What god reasons are there for skipping and mangling?

As far as I can see it only complicates matters and gains no advantage
(.. of course - I may be wrong - have overlooked things before ;) )

Comment 6

[Wayne Mery (:wsmwk)]

Do you still see this problem using Firefox 3.5?  Please update the bug, and close/alter bug if appropriate.

Comment 7

[Terje Rosenlund]

I have not checked the mangling part but div-tags are still skipped
so offsetParent-chain for td in html below placed in document.body will be:

table_1, document.body

Adding more break-tags (causing scroll) makes no difference

 <div id='div_1' style='height: 100px; overflow: scroll; width: 300px;'>
  <table  id='table_1'>
   <tr id='tr_1'>
    <td id='td_1'>
	 <br>
	 Terminating text	
	</td>
   </tr>
  </table>
 </div>

Comment 8

[Ralf Strobel]

I agree with Terje that the current behaviour still doesn't really make sense semantically. If you simply sum up all offsetTop values of the elements in the offsetParent chain, hoping to end up with the absolute document position of an element, the result is wrong if you have an element inside a scrolling page element.

Practically though, calculating the correct absolute document position for any element has become more trivial since FF3, thanks to getBoundingClientRect(). This gives the correct viewport position, which you can then correct for the scroll position of the document or any other parent scroll box.

Comment 9

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.