#9898 closed bug (fixed)
$.support.offsetFractions is always `false` if jquery.ui.position is included outside the head
| Reported by: | mattbasta | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | 1.12.0 |
| Component: | ui.position | Version: | 1.10.4 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Please see http://jsbin.com/hanabadu/1/
jquery.ui.position will only set offsetFractions to true if the code is executed in the <head> tag and the <script> that it's included with is not async or defer. This happens because there are two possible flows in jquery.ui.position: the first is used if a <body> exists, and the second if <body> does not.
When a <body> does not exist, a body element is created and injected into the DOM. In this case, the element that's used as part of the test has an offset that's expected (between 10 and 11).
When a <body> does exist, a <div> is created and injected into the DOM. This element is given an offset of -1000,-1000, which causes the test element's offset to be ~-989, which will never be in the expected range, and the test always fails.
Because of this bug, positions will always be rounded to the nearest integer for any site that does not include jquery.ui.position as a non-async, non-defer <script> in the head.
Change History (4)
comment:1 Changed 10 years ago by
comment:2 Changed 9 years ago by
| Status: | new → open |
|---|
comment:3 Changed 9 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | open → closed |
Position: Simplify fraction support test
Also makes the test lazy to avoid any potential layouts/recalculations during initialization.
Changeset: 3970e8c68146a3645f09d54735a40d5cf7eeef9e
comment:4 Changed 9 years ago by
| Milestone: | none → 1.12.0 |
|---|
Scott and I talked about this one, seems like the two cases could use the same negative top/left which would simplify the logic a bit. Definitely a bug as it is.