Search and Top Navigation
#8940 closed bug (wontfix)
Opened January 01, 2013 10:40PM UTC
Closed January 02, 2013 04:54PM UTC
Last modified October 14, 2013 12:24PM UTC
Draggable: Incorrect calculations with HTML padding and/or BODY width or margins
| Reported by: | jquery-dev | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | 2.0.0 |
| Component: | ui.draggable | Version: | 1.9.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
This bug affects only situations where padding is added to HTML and/or BODY is given a specific width and centered on the page. In these scenarios, containment and positioning are miscalculated. Both relatively- and absolutely-positioned draggable elements are affected.
The miscalculations vary depending on the combination of CSS used. Use this demo page to toggle each CSS setting to see how the draggables are affected...
http://layout.jquery-dev.net/test/draggable_position.html
Note that Draggable ''does'' handle BODY borders and padding correctly. It is only HTML padding and BODY margins that throw it a curve.
This demo uses jQuery 1.9.0b1 (to see if it helped), but the Draggable issues existed with previous versions of both jQuery and UI as well.
I found this bug because I have a widget for complex application/page layouts. Instead of adding unnecessary wrapper-divs to 'simulate' the BODY, I applied CSS directly to the HTML and BODY elements. This CSS works fine and is consistent across all browsers, even IE6, so it is perfectly valid CSS.
Everything else on such pages works normally, including my own size and position calculations for absolutely-positioned children of BODY, so the data returned by the browser is accurate and consistent.
This is admittedly a rare bug, but a bug nonetheless. I'll be happy to modify the linked demo page if it would be helpful to trace the problem. Or simply download the page - it is fully self-contained.
Attachments (0)
Change History (11)
Changed January 02, 2013 01:21PM UTC by comment:1
| milestone: | 1.10.0 → 2.0.0 |
|---|---|
| status: | new → open |
Changed January 02, 2013 04:54PM UTC by comment:2
| resolution: | → wontfix |
|---|---|
| status: | open → closed |
jQuery core has documented limitations:
Note: jQuery does not support getting the position coordinates of hidden elements or accounting for borders, margins, or padding set on the body element.
If you'd like to see this fixed, I suggest filing a bug against core.
Changed January 02, 2013 06:06PM UTC by comment:3
Replying to [comment:2 scott.gonzalez]:
jQuery core has documented limitations: > Note: jQuery does not support getting the position coordinates of hidden elements or accounting for borders, margins, or padding set on the body element. If you'd like to see this fixed, I suggest filing a bug against core.
.
Thanks for the info. It seems odd that position() cannot handle ALL valid CSS. I have no problem calculating these scenarios correctly so there is no technical challenge. jQuery's innerHeight() and outerHeight() also handle it correctly. Position() seems to be a weak link!
For the record, the statement on the position() page is inaccurate...
jQuery does not support getting the position coordinates of hidden elements or accounting for borders, margins, or padding set on the body element.
''Actually'' it handles BODY borders and padding correctly. It is BODY width, margins and HTML padding that it can't handle.
I'll wait until I have time to review the code to see why position can't handle this. If it's a simple fix, I'll create a fork and see if they will pull it.
Changed January 02, 2013 06:13PM UTC by comment:4
It's possible that some of the limitations have been removed over time. My guess is either the solution wasn't apparent or getting it to work consistently required too much code to add to core. If you can get this working in core, I'm sure you'd make a lot of people happy as a fair number of developers seem to be moving away from wrappers and styling html and body directly.
Changed January 03, 2013 03:58AM UTC by comment:5
This one intrigued me so I did a little digging. Visually you are correct that there are no issues width setting width, height, margin, padding, or border on the
bodyin any browsers back to IE6. There are some issues with setting widths and margins on
<html>in IE6 and 7, but not with padding as you had stated.
So as for why your demo isn't working it looks like at least part of the issue is
scrollHeightand
scrollWidthfrom core are incorrect - http://jsfiddle.net/QdKBn/. I want to do a bit more digging before filing anything though.
Changed January 04, 2013 02:23AM UTC by comment:7
I updated your fiddle with
inner/outer-width/heightand
offsetmethods, and added more complexity to the CSS for both HTML and BODY. '''In Chrome, ALL ''these'' methods give perfectly accurate results.''' It ''seems'' like the necessary methods are available internally for
position()to use, so it's odd that it is wrong while all other dimensional methods are correct (for modern browsers at least). Perhaps all it needs is some logic tweaking to fix the issue?
Replying to [comment:5 tj.vantoll]:
This one intrigued me so I did a little digging... it looks like at least part of the issue isscrollHeightandscrollWidthfrom core are incorrect - http://jsfiddle.net/QdKBn/. I want to do a bit more digging before filing anything though.
Changed January 04, 2013 03:02AM UTC by comment:8
| _comment0: | The value for {{{scrollHeight}}} and {{{scrollWidth}}} on {{{document.body}} is inconsistent between WebKit and all other browsers. View http://jsfiddle.net/QdKBn/2/ in the latest Chrome and Firefox and compare values to see what I'm talking about. \ \ In this case I would say that WebKit is incorrect because the {{{scrollHeight}}} and {{{scrollWidth}}} *should* be {{{200}}}, since the body is explicitly set to a width/height of {{{200px}}} in the CSS. Both are 200 in Firefox, Opera, and IE 7 - 10. \ \ Since draggable's code is using both of these properties in its {{{containment}}} logic (see https://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.draggable.js#L426), this is absolutely contributing to the issue you were having in your original example. → 1357268635041637 |
|---|
The value for
scrollHeightand
scrollWidthon
document.bodyis inconsistent between WebKit and all other browsers. View http://jsfiddle.net/QdKBn/2/ in the latest Chrome and Firefox and compare values to see what I'm talking about.
In this case I would say that WebKit is incorrect because the
scrollHeightand
scrollWidth*should* be
200, since the body is explicitly set to a width/height of
200pxin the CSS. Both are 200 in Firefox, Opera, and IE 7 - 10.
Since draggable's code is using both of these properties in its
containmentlogic (see https://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.draggable.js#L426), this is absolutely contributing to the issue you were having in your original example.
Changed February 11, 2013 01:04PM UTC by comment:9
I've discovered that containment doesnt work correctly even if body and html dont have padding or margins and width. But my main block has been centered on the page using margin: 0 auto; and max-width is set. Also, one of the draggable parents has 20px padding. And all of it makes containment to work incorrect.
Changed February 12, 2013 03:16AM UTC by comment:10
Replying to [comment:9 alxcube]:
I've discovered that containment doesnt work correctly even if body and html dont have padding or margins and width. But my main block has been centered on the page using margin: 0 auto; and max-width is set. Also, one of the draggable parents has 20px padding. And all of it makes containment to work incorrect.
That is likely #6869.
Changed October 14, 2013 12:24PM UTC by comment:11
#9599 is a duplicate of this ticket.