Module defines jQuery UI files independently from Core. Can cause CSS priority issues in AJAX calls

Confirming the issue from 🐛 Overlay blocking image upload modal in Drupal 10.1 Fixed , taking a look at the changes, I'm not sure if it was focal_point's fault or is wrong logic in the jquery_ui module? Can the jquery_ui maintainers tell easily perhaps?

In general, I can say that it's of course unexpected that with jquery_ui installed, the CSS file priority is different. That bug was really hard to find. The priority / loading order should stay the same, as described in the proposed resolution, but focal_point declared dependencies in a given order that may also have caused this specific bug.

See Drupal 10.1 change records for details how the aggregation system was changed, which may have caused this bug: https://www.drupal.org/project/drupal/releases/10.1.0 →

Using one set of files sounds good, but I don't think we detect duplicate files as such. I might be better to force the jquery_ui libraries as dependencies of the core libraries, then remove the core versions of the files from those library definitions - then you know that one file is coming from one library definition.

This could potentially be related to 🐛 Library order asset weights do not work properly when a large number of javascript files is loaded between two jQuery UI libraries Fixed , or it could be a side effect of the asset generation changes themselves.

Can you check what happens with aggregation disabled? If so that would narrow it down to 🐛 Library order asset weights do not work properly when a large number of javascript files is loaded between two jQuery UI libraries Fixed a bit more closely.

It does still happen with aggregation disabled. I think it's down to there being two distinct assets in the two distinct libraries.

Removing core's asset definitions and substituting dependencies on the jquery_ui module's libraries sounds like a good path forward, thanks.

Opened MR 8 with an implementation.

New jquery_ui_library_info_alter() logic replaces core library jQuery UI files with dependency declaration(s) where possible. Where that is not possible, due to the site not having the sub-module for a particular JQUI library installed, the file definition in the core library is instead replaced using the file & definition from the jquery_ui library data.

At first I tried just replacing the files that are actually present in declared libraries with dependencies - and leaving any other JQUI assets in core libraries alone. However, I found this caused ordering problems. The jquery_ui module uses a -11 weight across the board for its JS files, and the recommended approach of dependencies within a network of library definitions to establish ordering. Core's drupal.autocomplete and drupal.dialog libraries - as well as all the jquery_ui* libraries included in 9.x - take a different approach, declaring everything in one library, and using lesser weights like -11.9 and -11.8 to order files within the one library. On a test site without certain submodules like jquery_ui_autocomplete enabled, that was resulting in dependent files that were still declared on the core library - like autocomplete-min.js - being included before core library dependencies like widget-min.js that are always going to be provided by the jquery_ui/core library. Which results in javascript errors.

So I switched to re-working all assets found in core libraries, by one method or another, based on a comprehensive mapping of jquery_ui.libraries.data.json.

Changing this back to needs work since there is nothing to compare in the MR.

See 🐛 Remove duplicate jQuery UI JavaScript and CSS files Needs review that has a fix for all core libraries by replacing the individual files instead of adding a library dependency which can cause resolved library weighting issues.