Opened 10 years ago
Closed 10 years ago
#8763 closed bug (fixed)
Position: getScrollInfo() swapped width and height
Reported by: | CR | Owned by: | Scott González |
---|---|---|---|
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.
Change History (12)
comment:1 Changed 10 years ago by
Owner: | set to CR |
---|---|
Status: | new → pending |
comment:2 Changed 10 years ago by
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...
comment:3 Changed 10 years ago by
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.
comment:4 Changed 10 years ago by
Resolution: | notabug |
---|---|
Status: | closed → reopened |
comment:5 Changed 10 years ago by
I'd like to take a shot at proving the bug here. jsfiddle coming at some point some.
comment:6 Changed 10 years ago by
Owner: | changed from CR to mikesherov |
---|---|
Status: | reopened → assigned |
comment:7 Changed 10 years ago by
Sorry, reading this (and the code) again, it does sound like the logic might be reversed.
comment:8 Changed 10 years ago by
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?
comment:10 Changed 10 years ago by
Milestone: | 1.10.0 → none |
---|
comment:11 Changed 10 years ago by
Milestone: | none → 1.10.2 |
---|---|
Owner: | changed from mikesherov to scott.gonzalez |
Summary: | jquery.ui.position.js getScrollInfo() swapped width and height → Position: getScrollInfo() swapped width and height |
comment:12 Changed 10 years ago by
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?