Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 295778

jQuery UI library order is incorrect when a large number of javascript files is loaded between two jQuery UI libraries

$
0
0

Problem/Motivation

Following the #3113400: Deprecate more jQuery UI library definitions update, it appears that the order of jQuery UI assets can change depending on whether there is a sufficiently large library loaded between two jQuery UI dependent libraries.

The bug is a side-effect of using non-integer weights for the jQuery UI libraries.

In particular, this AssetResolver::getJsAssets() logic:

$options['weight'] += count($javascript) / 1000;

Based on @jmickela's findings:

The javascript array is an array of files currently staged to be included, and grows by one with every iteration though the array of libraries. If all the weights were integers this wouldn't have an impact on the loading order, but the weights in the jQuery UI library use decimals now.

If two files are processed far enough apart from each other in the array, but have weights very close to each other, this change is enough to change the order they get loaded.

Widget's weight starts at -11.8, and Controlgroup at -11.7, if there's exactly 100 files in the array between them then they'll end up with the same weight, if there's 101 files then Controlgroup will get loaded before widget. I just checked an on the page I was testing on, I'm getting around 200 individual files.

Steps to reproduce

Use a render array similar to:

[
  '#attached' => [
    'library' => [
      'core/drupal.dialog',
      // This library contains at least 100 javascript entries.
      'jqueryui_library_assets_test/many-dependencies',
      'core/drupal.autocomplete',
    ],
  ],
];

Proposed resolution

TBD.

Since this is jQuery UI specific and because it's implementing its weight using a non-standard approach as part of future deprecation work, would the recommended resolution be to change the fractional part of the weights from tenths to thousandths so that it's much less likely to run into the bug?

The alternative is to try and revisit the AssetResolver logic and see if it can be made more deterministic without introducing its own subtle bugs e.g. changing the divisor from 1000 to 3000 or higher.

Remaining tasks

Provide an issue fork/patch.

User interface changes

None

API changes

TBD

Release notes snippet

TBD


Viewing all articles
Browse latest Browse all 295778

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>