Problem/Motivation
Discovered in #3113556: Change Views UI to use drupal.dialog instead of jquery.ui.dialog, there is an issue that intermittently occurs on scroll/resize
To reproduce
- Use chrome
- Go to /admin/structure/views/view/content
- Open the Tab: Content dialog (under PAGE SETTINGS)
- Gradually reduce the browser viewport height, and the dark line will appear above the buttonpane at specific heights.

Proposed resolution
Remove dialog.views.js and this CSS rule that is based on a selector that is only added by that file
.views-ui-dialog.views-ui-dialog-scroll .ui-dialog-titlebar {
border: none;
}When these are removed the bug goes away.
It looks like the purpose of dialog.views.js is for resizing, which is now taken care of by the drupal.dialog.ajax library as of #3113556: Change Views UI to use drupal.dialog instead of jquery.ui.dialog. drupal.dialog.ajax does this without the bug happening, and presence of dialog.views.js also means resizing work is happening twice.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #39 | without-patch.png | 556.11 KB | smustgrave |
| #35 | reroll_diff_32-35.txt | 3.19 KB | raman.b |
| #35 | 3118010-35.patch | 7.86 KB | raman.b |
| #32 | interdiff_13-32.txt | 3.23 KB | Kumar Kundan |
| #32 | 3118010-32.patch | 7.77 KB | Kumar Kundan |
Comments
Comment #2
bnjmnmThis patch addresses the issue

Claro's CSS was also updated to remove the rule specific to this no-longer-present JavaScript. The rule is also present in Stable/Stable9 but of course needs to stay for BC.
Comment #3
kristen polI'll take a look.
Comment #4
kristen polThanks for the patch. I still need to test this but I've reviewed the code:
1) I reviewed the removed JavaScript and it is only for resizing the dialog
2) I checked all the code to see if js/dialog.views.js was added anywhere else and it was only in views_ui.libraries.yml (and it is removed from that libraries file in the patch)
3) I looked at the CSS changes and they seem ok
4) I checked other CSS for places where it had similar CSS to Claro and found:
in:
So I'm wondering if the same issue is present for these themes and the same CSS change is needed for those files.
Comment #5
kristen polComment #6
sanjayk commented@Kristen Pol
I have removed css from rest of file.
Comment #7
sanjayk commentedUpdated file
Comment #8
kristen polThanks for the update @sanjayk. Fyi, it's good to provide an interdiff file when making changes so it's easier to see what has changed.
1) In reviewing the changes, I see that:
was removed from:
and no other changes were made which is as expected.
2) The patch applies cleanly:
3) This will need to be manually test for these themes for sure:
but not sure what else because this CSS:
core/modules/views_ui/css/views_ui.admin.theme.cssis in the module.
Comment #9
bnjmnmI’m glad to see multiple people helping with this issue! It will be nice to clean that up.
This is looking good, but nothing in the Stable or Stable9 themes should be changed. The Stable themes exist to provide a backwards-compatible “fence” that contrib themes can rely on to not change.The only exception to this is if the change addresses a bug or similar problem.
In this case, the presence of that CSS is not causing any problems. Rather, the removal is because it’s no longer needed. It should still remain in the Stable themes because 1) Stable promises to only make changes that are absolutely necessary 2) There’s a possibility, however remote, that a theme based on Stable is leveraging that CSS rule.
Comment #10
kristen polThanks @bnjmnm. That is good to understand. So it needs to go back into
stableandstable9. Is there an issue removing it from:core/modules/views_ui/css/views_ui.admin.theme.css? If so, then your patch from #2 is the keeper. Otherwise, we need a new patch with just that file updated.
Comment #11
bnjmnmThanks @Kristen Pol
Re #9
No issue with removing there as it's not in a theme that made the "stable promise"
This is diffs from #2 and was updated to remove the no-longer-needed rule from views_ui.admin.theme.css.
Comment #13
bnjmnmTest failure was in the test that tracks assets that deviate from Stable. This is an acceptable change so I just added the altered CSS file to the test's skip list.
Comment #14
kristen polAssigning to myself to review.
Comment #15
kristen polI'm getting pulled away for a bit so unassigning for now in case someone else can review.
Comment #16
kristen polReviewed #11 and #13 and these changes seem fine based on the discussion. Test pass now so this just needs manual testing. I can't get to that tonight unfortunately.
Comment #17
kristen polI tested on #13 on Chrome and do not see the dark line when I resize the window up and down.
Comment #18
kristen polI should have noted that I was able to reproduce the issue without the patch.
Comment #19
kristen polAdding tag as I worked on this yesterday for the Bug Smash Initiative.
Note that I didn't marked RTBC because it might be good for someone with more experienced JS/CSS chops to scan the patch.
Comment #20
sanjayk commentedComment #21
lendudeWe have some Javascript tests that use the dialog, but we don't have anything that tests the resizing (as far as I can find). While I don't advocate testing this pixel perfect, adding a test that the resize still happens would not be a bad thing I think.
Comment #22
sanjayk commentedComment #23
nod_I'm all for removing code. So patch is good on that front +1
On the testing front today we have that: https://git.drupalcode.org/project/drupal/-/blob/9.0.x/core/tests/Drupal... so not a lot.
If we want to add a test I don't think the test needs to be view ui specific might be enough to check that the size of the dialog changed before and after browser resize in that method.
Comment #24
kristen pol@nod_ Thanks for the input!
I think I'm missing the point. From what you wrote, it looks like you are suggesting that we might add a test to see if the dialog size changes. But, this bug isn't that the dialog doesn't resize properly, just that there is a slight visual anomaly when it does resize. Shouldn't the test added be for the bug in question?
Comment #25
tanubansal commentedTested with above mentioned points and patch.
Its appearing good on chrome browser. RTBC + 1
Comment #26
kristen pol@tanubansal Thank you for your help but it was already manually tested in #17. Please don't duplicate work if possible. Thanks.
Comment #27
nod_It was to complement #21. I think the idea was to make sure the resize worked because we broke views UI quite frequently in the past.
Comment #28
kristen pol@nod_ Thanks for the update. Tagging for tests.
Comment #29
kristen polBack to "Needs work" for tests.
Comment #30
Kumar Kundan commented@Kristen Pol I am trying to work on the test cases. I just try to apply the path(#13) but it failed & I found StableDecoupledTest.php not available.
Can you pls guide me to resolve this issue.
Comment #31
bnjmnmStabledecoupledtest is no longer part of Drupal core, so the changes to that file in the patch are not needed either. Applying the patch with default settings will fail, but it should be possible to apply the patch with the —reject flag. Consult the git documentation for details and other options of —reject does not work for you: https://git-scm.com/docs/git-apply.
Comment #32
Kumar Kundan commentedComment #33
Kumar Kundan commentedWork only for the test cases & updating it's status to need review.
Comment #35
raman.b commentedRe-roll for 9.2.x
Comment #39
smustgrave commentedTested on both claro and seven and was not able to reproduce. Going to close out but if still an issue please reopen.