Search and Top Navigation
#8763 closed bug (fixed)
Opened November 01, 2012 12:46PM UTC
Closed February 26, 2013 01:59PM UTC
Position: getScrollInfo() swapped width and height
| Reported by: | CR | Owned by: | scottgonzalez |
|---|---|---|---|
| Priority: | minor | Milestone: | 1.10.2 |
| Component: | ui.position | Version: | 1.9.1 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
I wanted to use the scrollbar detection/calculation of jquery-ui-position and wondered why it switched the results.
In jquery.ui.position.js line 66 says:
return {
width: hasOverflowX ? $.position.scrollbarWidth() : 0,
height: hasOverflowY ? $.position.scrollbarWidth() : 0
};
If I have an overflowing content in horizontal (x) direction, I get a scrollbar on the bottom of the element, that means the height value has been modified. So in my opinion it should return the scrollbarwidth as the height attribute and not as the width.
Attachments (0)
Change History (12)
Changed November 01, 2012 02:02PM UTC by comment:1
| owner: | → CR |
|---|---|
| status: | new → pending |
Changed November 01, 2012 02:39PM UTC by comment:2
| status: | pending → new |
|---|
Think of a simple page which has scrollbars on the right. That means, the content's height is too large to fit in. Code would correctly detect hasOverflowY=true and return somthing like {width:0,height:20}.
Now for example I would want to calculate the coordinates of an element to position it. And for that I would need the width of that (possible) scrollbar on the right. So I would expect to find this value in "width" attribute of the result instead of the "height".
I don't know If that affects other calculations in position or the "mind-switching" of the values is going through the rest of the code. For me this just doesn't seem to be right, maybe my way of thinking just differs from yours...
Changed November 01, 2012 02:57PM UTC by comment:3
| resolution: | → notabug |
|---|---|
| status: | new → closed |
It sounds like you don't have a bug to report. If you have a test case that is failing, please let us know.
Changed November 01, 2012 03:36PM UTC by comment:4
| resolution: | notabug |
|---|---|
| status: | closed → reopened |
Changed November 01, 2012 03:36PM UTC by comment:5
I'd like to take a shot at proving the bug here. jsfiddle coming at some point some.
Changed November 01, 2012 03:37PM UTC by comment:6
| owner: | CR → mikesherov |
|---|---|
| status: | reopened → assigned |
Changed November 01, 2012 04:57PM UTC by comment:7
Sorry, reading this (and the code) again, it does sound like the logic might be reversed.
Changed November 03, 2012 09:52AM UTC by comment:8
Switching around hasOverflowX and hasOverflowY doesn't seem to make a difference in practice, at least for the position utility. Does someone have a case where it actually produces the wrong result?
Changed November 03, 2012 12:10PM UTC by comment:9
That's what I'm looking into
Changed January 25, 2013 09:23PM UTC by comment:10
| milestone: | 1.10.0 → none |
|---|
Changed February 26, 2013 01:59PM UTC by comment:11
| milestone: | none → 1.10.2 |
|---|---|
| owner: | mikesherov → scott.gonzalez |
| summary: | jquery.ui.position.js getScrollInfo() swapped width and height → Position: getScrollInfo() swapped width and height |
Changed February 26, 2013 01:59PM UTC by comment:12
| resolution: | → fixed |
|---|---|
| status: | assigned → closed |
Position: Fix orientation check for scrollbar widths. Fixes #8763 - Position: getScrollInfo() swapped width and height.
Changeset: e9c04bfa430eb6b18e7fe1be2f8d162e01181a94
It looks to me like the code does exactly what you're saying. Also, it sounds like you're not even reporting a bug against position, but asking a question about how to use some of position's code outside of position. Can you please provide a reduced test case showing the problem you're having?