Opened 6 years ago

Closed 4 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 6 years ago by dmethvin

Can you put together a simple repro case just so we know we're looking at the same thing?

comment:2 Changed 6 years ago by dmethvin

Cc: dmethvin added

comment:3 Changed 6 years ago by mattbasta

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 6 years ago by dmethvin

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 6 years ago by mattbasta

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 5 years ago by Scott González

Owner: set to mattbasta
Status: newpending

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 5 years ago by Scott González

Position: Simplify fraction support test

Also makes the test lazy to avoid any potential layouts/recalculations during initialization.

Fixes #9898 Ref #9899

Changeset: 3970e8c68146a3645f09d54735a40d5cf7eeef9e

comment:4 Changed 4 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

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!

Note: See TracTickets for help on using tickets.