Opened 9 years ago
Closed 8 years ago
#9899 closed bug (invalid)
jquery.ui.position's offsetFractions test performs a full-page layout recalculation
| Reported by: | mattbasta | Owned by: | mattbasta |
|---|---|---|---|
| Priority: | minor | Milestone: | none |
| Component: | ui.position | Version: | 1.10.4 |
| Keywords: | Cc: | dmethvin | |
| Blocked by: | Blocking: |
Description
The offsetFractions test in jquery.ui.position forces a full-page layout recalculation. For large pages, this can be an extremely expensive operation.
This happens here: https://github.com/jquery/jquery-ui/blob/master/ui/position.js#L507
I've tested and confirmed this in Chrome 33 and observed the perf hit in Firefox. Unfortunately, Chrome is the only browser that provides granular information on layout recalculation, so I cannot confirm that the same line causes the issue in Firefox.
This issue will occur on any page that includes jquery.ui.position outside the <head> or applies defer or async to the script tag.
Change History (8)
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
| Cc: | dmethvin added |
|---|
comment:3 Changed 9 years ago by
I'm working to put together a demo page that clearly exhibits the problem. If the demo doesn't have a sizable number of elements, the issue isn't very apparent.
comment:4 Changed 9 years ago by
Thanks! We can always see the result in Chrome dev tools, I'm a bit surprised it's a full-page layout.
comment:5 Changed 9 years ago by
Here's some less-than-great insights into what I'm seeing on my end. First, this is a screenshot of the style recalculation that the jquery.ui.position script makes:
http://i.imgur.com/0S9rbio.png
The browser seems to be doing some optimization that's making the exact action that causes the recalculation non-obvious. This second screenshot shows a layout recalculation that's performed immediately after the style recalculation:
http://i.imgur.com/lUrw5TP.png
When I minify the JS, the exact line numbers or calls that cause it get a little fuzzed. I've got some unstashed changes that I can't clean up at the moment, so I can't show stats from my dev environment with a very heavy page layout (where the cost is a *bit* more than 2ms). I'll try to post something a bit later today or tomorrow morning that will hopefully make the issue a bit more visible.
comment:6 Changed 8 years ago by
| Owner: | set to mattbasta |
|---|---|
| Status: | new → pending |
I'm not seeing the same results testing locally (with 1.10.4 or master). The only recalculations I'm seeing are from core's support tests or during the actual positioning of the elements. Please provide a reduced test case for us to work with if you're still having this problem.
comment:7 Changed 8 years ago by
Position: Simplify fraction support test
Also makes the test lazy to avoid any potential layouts/recalculations during initialization.
Changeset: 3970e8c68146a3645f09d54735a40d5cf7eeef9e
comment:4 Changed 8 years ago by
| Resolution: | → invalid |
|---|---|
| Status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
Can you put together a simple repro case just so we know we're looking at the same thing?