Opened 15 years ago

Closed 9 years ago

#3671 closed defect (patchwelcome)

parentConstrainedMover: body margin not taken into account by IE 6

Reported by: guest Owned by: Eugene Lazutkin
Priority: high Milestone: 1.9
Component: HTML Version: 0.9
Keywords: needsreview Cc:
Blocked By: Blocking:

Description (last modified by sjmiles)

More specifically, it looks like dojo._getMarginBox is incorrect in IE 6. Have not actually tested though with multiple nested divs. To reproduce, create a parentConstrainedMover and set body margin!=0. Adding a border to the parent and dragging a node around shows that the node is constrained to a box up and to the left of the parent by the margin size.

Attachments (1)

html_body_bug.html (1.1 KB) - added by Eugene Lazutkin 15 years ago.
place it in dojo/tests/_base/

Download all attachments as: .zip

Change History (14)

comment:1 Changed 15 years ago by Adam Peller

Component: GeneralHTML
Owner: changed from anonymous to sjmiles

comment:2 Changed 15 years ago by sjmiles

Owner: changed from sjmiles to Eugene Lazutkin

comment:3 Changed 15 years ago by sjmiles

Don't want to take HTML tickets that are expressed in terms of DnD modules. Need a test case that doesn't use DnD.

comment:4 Changed 15 years ago by Eugene Lazutkin

Component: HTMLDnD
Status: newassigned

I am reassigning it temporarily to DnD.

comment:5 Changed 15 years ago by Eugene Lazutkin

Milestone: 0.9

comment:6 Changed 15 years ago by Eugene Lazutkin

Component: DnDHTML
Owner: changed from Eugene Lazutkin to sjmiles
Status: assignednew

I was able to reproduce this problem with a simple program (attached). Regardless of body margins it always returns {l: 0, t: 0, ...} on IE6 and IE7. On other browsers l looks about right, but t is consistently smaller than the body top margin. Strange. I didn't analyze the width and height attributes. Take a look for yourself.

Changed 15 years ago by Eugene Lazutkin

Attachment: html_body_bug.html added

place it in dojo/tests/_base/

comment:7 Changed 15 years ago by sjmiles

First: margins on the offsetParent are not expected to affect the margin-box of a child. The margin-box of a node is relative to the content-box of it's offsetParent.

Iow, 0,0 is the origin of the content-box of the offsetParent in the reference frame of the child, and is the correct result regardless of margin on the offsetParent.

This rule is intended to allow logical adjusting of child nodes in the content space of parent nodes, and vice versa.

On non-IE browsers that body margins are included in the offset values for the child (unless the child of body that is the offsetParent of the target node has position). This strikes me as a flaw in non-IE browsers (gasp), but I will have to review the standards documentation.

Assigning position: relative to the test node removes the effect. If test had other offsetParents, then the effect could be eliminated by giving position to the offsetParent that is child of body.

I will try to see if there is a way to patch this problem at html.js, but make sure you understand the first sentence of this comment to understand the impact on DnD.

Note that on non-IE (with 0 body margin) you are getting a sub-pixel t because the default margin height on <p> is in EMs which computes to a floating point value in pixels. Dojo provides the true floating point value; truncated, it's just 0.

comment:8 Changed 15 years ago by sjmiles

Milestone: 0.91.0

Unfortunately, there are major browser difference with respect to how margins are presented and we need some overhaul. We won't be able to get this done in time for 0.9 GA.

comment:9 Changed 14 years ago by sjmiles

Milestone: 1.11.2

comment:10 Changed 14 years ago by sjmiles

Description: modified (diff)
Milestone: 1.2future

comment:11 Changed 10 years ago by ben hockey

Keywords: needsreview added

comment:12 Changed 10 years ago by bill

Owner: changed from sjmiles to Eugene Lazutkin
Status: newassigned

comment:13 Changed 9 years ago by dylan

Milestone: future1.9
Resolution: patchwelcome
Status: assignedclosed

This won't be relevant for 2.0 (IE6 support). If a patch is contributed, we'll review it, otherwise it won't be fixed.

Note: See TracTickets for help on using tickets.