#9899 closed bug (invalid)

Opened March 06, 2014 07:16PM UTC

Closed April 02, 2015 08:51AM UTC

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.

Attachments (0)
Change History (8)

Changed March 06, 2014 09:00PM UTC by dmethvin comment:1

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

Changed March 07, 2014 12:59AM UTC by dmethvin comment:2

cc: → dmethvin

Changed March 07, 2014 09:41PM UTC by mattbasta comment:3

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.

Changed March 07, 2014 09:56PM UTC by dmethvin comment:4

Thanks! We can always see the result in Chrome dev tools, I'm a bit surprised it's a full-page layout.

Changed March 10, 2014 07:50PM UTC by mattbasta comment:5

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.

Changed March 18, 2015 02:19PM UTC by scottgonzalez comment:6

owner: → 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.

Changed March 18, 2015 02:58PM UTC by Scott González comment:7

Position: Simplify fraction support test

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

initialization.

Fixes #9898

Ref #9899

Changeset: 3970e8c68146a3645f09d54735a40d5cf7eeef9e

Changed April 02, 2015 08:51AM UTC by trac-o-bot comment:8

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!