Change Views UI to use drupal.dialog instead of jquery.ui.dialog

We do have some js tests of Views UI but I don't know if it's enough. I think we need a before/after screenshot here to see how it all looks.

Attached are screenshots of Views UI using jQueryUI dialog vs. drupal.dialog. The only difference I could find was a welcome one -- when jQueryUI dialog is used directly, the toolbar is still interactable when modals are open - this should not be the case. This is fixed by using drupal.dialog.

My manual testing included IE11, Firefox, Safari, confirming that the dialogs were not suddenly moveable or resizable via pointer, and verifying no changes in keyboard navigation or screenreader output.

Based on my review in #6, this can get RTBC'd.

+++ b/core/modules/views_ui/src/ViewEditForm.php
@@ -110,7 +110,7 @@ public function form(array $form, FormStateInterface $form_state) {
+    $form['#attached']['library'][] = 'core/drupal.dialog';

Based on Drupal\Core\Render\MainContent\ModalRenderer, we should add dependency to core/drupal.dialog.ajax here.

Fixed #8

Looks like switching the library does introduce some unwanted artifacts. I discovered this while testing #9, but it also happens with #3. It does not happen on HEAD.

While scrolling with the modal open, a dark border intermittently appears between the button pane and content. If scrolling stops while this is visible, it will remain in the modal.

I believe this is a conflict between the JS added by drupal.dialog vs dialog.views.js. The functionality added by dialog.views.js is behavior that is triggered while scrolling, so it's not surprising that scrolling would be where a conflict was seen.

It sure seems like removing dialog.views.js from the views_ui.admin library would take care of this., since core's dialog handling *seems* to accomplish everything this does. It does add a .views-ui-dialog-scroll class that is targeted in css, which was added in this issue/comment: #1851414: Convert Views to use the abstracted dialog modal. If it turns out that dialog.views.js is unnecessary, it's quite possible this rule is also unnecessary:

.views-ui-dialog.views-ui-dialog-scroll .ui-dialog-titlebar {
  border: none;
}

@bnjmnm I tried to reproduce the problem on Chrome, Firefox and Safari but all of them work as expected. Which browser and browser version did you use?

Turns out the issue I found in #10 happens on HEAD as well. It only occurs on specific viewport heights and my tests with patches happened to be at those heights, while my tests on HEAD did not. Based on this being a pre-existing issue, this can go back to RTBC.

At reliable way to reproduce the issue:
- Use chrome
- Go to /admin/structure/views/view/content
- Open the Tab: Content dialog
- Gradually reduce the browser viewport height, and the dark line will appear at specific heights.

I also confirmed that removing dialog.views.js does fix this. That's out of scope for this issue, so I'm about to create a followup.

Tested this manually using the instructions in #12 and I could reproduce the problem, both before and after the patch.

Committed 4b32a6e and pushed to 9.0.x and 8.9.x. Thanks!

Given that this has some positive implications on the interaction with toolbar as described in #6, we might want to consider backporting this to 8.8.x too.

Here's the followup: #3118010: Resize bug with dialog.views.js

Couldn't this potentially have some disruptive impacts for Views-extending contrib by changing what JS is loaded on the page? Maybe we're OK with that since it's an admin form.

Also, should this have come with a cache clear? (If so, that would be a reason not to backport it to 8.8.x since otherwise 8.8.4 would not require any cache clear.)

Couldn't this potentially have some disruptive impacts for Views-extending contrib by changing what JS is loaded on the page?

I guess someone could be for example detaching the library using form alters, but that seems unlikely. This doesn't feel too risky for frontend related extensions because jQuery dialog is still being used under the hood. This means that any jQuery events they might be using are still triggered. What is also interesting, is that even before this change, the core/drupal.dialog.ajax library was inserted to the page with ajax, meaning that the libraries are only different at the state where dialog has not been inserted using ajax yet.

Also, should this have come with a cache clear?

I tested manually that this doesn't need a cache clear. It seemed like Views UI had disabled caching on the View edit form.

I think it's fine to leave this just to 8.9.x even though this could be eligible for 8.8.x. Committers are very busy at the moment and I don't want to add this to release manager's workload.