Error: Cannot read properties of undefined (reading 'settings') with dialog.position.js

Thanks for reporting.

As a bug it will need a test case showing the issue. Believe core has method for testing console errors.

Just ran into the same issue when uploading a file in a media within a modal. The result is a broken widget, which isn't usable anymore.
The ui-widget-overlay ui-front is blocking the UI.

Increasing priority as of #7, but I'm wondering why we're the second ones experiencing this, might be caused by contrib.
Already removed all other patches to ensure it's not a patch braking this.

If it helps: This seems to happen since the upgrade to Drupal 10.1.1 and before this issue I see #3351600: ckeditor5.dialog.fix.js throws "Uncaught TypeError: event.target.classList is undefined" in Firefox in Drupal 10 with the editor in a modal in the console, which *might* be (un)related.

Changing the admin theme doesn't fix it. I use Gin and also tried Claro, but with the same results.

Interesting, just with disabling CSS / JS cache, clearing caches and coming back, the error in the console is gone, but I still see the ui-widget-overlay ui-front overlay above the modals, blocking all editing, once a second modal is opened. So maybe this is unrelated? Super strange things going on...

Okay in the end it turned out, that it was this issue for us: #3371179: Overlay blocking image upload modal in Drupal 10.1 still I dont know why this error in the console disappeared in #9. -.-

I am occasionally getting this on a D9.5.3 site. It was consistently working for many months but has recently been broken. Originally i thought it was only admin users using Firefox as it seemed to always work in Chrome or for non-admins. But just now i see the issue for a non-admin in Chrome.

This patch does not apply. Will try manual patch.

with a very small sample size of testing (since it wasn't consistently occurring); this seems to have fixed the issue.

spoke too soon. With the fix from #2, i still see this issue.

I had this issue with undefined and also similar with null with Drupal 10.1.5.
Added null check to the patch #2 and created MR.
But we still need a tests.

I'm also experiencing this when using AJAX requests in modals on Drupal 10.1.6.
But looking at the solutions provided in #2 and the MR it only masks the problem and does not solves it.

My use case:

• Have a custom or contrib StylePlugin extending the StylePluginBase from views. For example UI Patterns 2.x
• Have that plugin work with a subform state so it rebuilds on selecting an option
• Without the patches it throws the error and does not resize the modal, only after manually resizing the browser window so it triggers the resize event
• With the patches it does not throw the error but does not resize the modal, only after manually resizing the browser window so it triggers the resize event

Same as tim-diels I found that #2 & MR are simply ignoring the error and not solving the problem.
The issue I was finding is that the error is caused by failing to pass data over to the resetSize function.

I found if I removed the debounce method the error went away and also for me the auto resizing of modal/dialog was happening upon load.

I'm not totally sure how we can write tests for this though.

I don't understand why 😂 but #19 works 🎉

I've reviewed patch #19, but unfortunately, it's not working for me. I made a few changes based on the guidance provided in this Stack Overflow answer.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Bot changes updated in this patch.

MR appears to have failures.

Just had this reported on a site that's on 10.1. This is using the media widget on a media field (on a comment, not that this would matter) and only happens very intermittently.

Given the intermittent nature of the bug, I'm removing the 'needs tests' tag - we should double check we have test coverage for the media widget, but getting consistent steps to reproduce with core, that are then reproducible with functional javascript testing may not be possible here.

Rebased the MR so that it gets passed cspell, but it's now failing the tabbable shim nightwatch test which either indicates a bug or may need updating: https://git.drupalcode.org/project/drupal/-/jobs/1270916

Bumping back to major because this renders the media widget unusable with no workarounds and appears to be affecting other areas like layout builder too.

Re-rolled patch from #23 for D10.3

Re-rolled patch from #23 for D10.1

I've tried with #27 with drupal 10.3 but doesnt work.

#27 works for me on 10.3 in terms of resolving the console error and allowing other processes to run, but now the dialog modal is aligned right instead of centered. If I resize the browser window, it snaps back to being centered.

(I was running into this issue using the Footnotes plugin with CKEditor 5. The Footnotes modal would open, but the Link button within the Footnotes modal's WYSIWYG would not launch its dialog without this patch.)

I've made a MR to change to put this:

.ck-balloon-panel {
  z-index: 10000 !important;
}

Because with the old value the balloon was under and invisible. I'm using layout paragraphs, by the way, and now i can see the balloon when i click in the link button of ckeditor.

I don't quite get, why we have multiple MRs open here. MR !8892 is on current 11.x and ALMOST similar to MR !5266, but the most important change (removing the debounce call) is missing.

Since "MR !8892" is on current 11.x I'll just readd the changes of the old MR, and we get a working solution. :)

Alright, tests are failing. I asked in Slack, if the changes suggested here are going in the right direction. Let's wait for some feedback from them and overhaul the tests after a confirming feedback! 👍

Alright, "3356667-undefined-settings-dialog-position-simple-fix" contains a simple fix using the JS optional operator. Thanks to @_nod for pointing it out over @ Slack!

Works great and without much fuzz! Tests should also succeed. Please review!

Great work all, thanks @Grevil! I just reviewed the changes and tested them, fix works as expected.
Should we add a comment to explain situations when event.data can be empty?

Another option I would have liked code-wise is to return early, if event.data is null and not execute the event.data-related code at all. Setting this RTBC now for final discussions.

Just had a look at the comments here and found out, that there was already a patch in #2 by @Robert Ngo, which has the same logic as the current MR !9070. It fixes the issue in our use case, but reading #18 and #19, it might not be enough for all use cases?

Should we create a follow-up issue regarding the withstanding issue described in #18 and #19? Or should we try and make their suggested changes (now part of MR !8892) get merged in core?

Unsure how to proceed here. Both patches work as a fix for our use case, but tests are failing for MR !8892 and the changes there are quite more drastic, then the ones in MR !9070.

I need to look more closely at what's going on

Thanks @nod_! 🙂

I have tried all the patches and MRs of this issue and none of them work in Drupal 9.5.11.

I will try to investigate what I can in case I can shed some light :).

Re-rolled patch from MR! 8892 for Drupal 10.2.x

Here is patch for the latest MR.

Not sure which MR is to be reviewed now and there is a mix of patches now. Should be cleaned up some.

Bit of clean-up:

1. Hiding MR that #18 and #19 confirm just mask the problem rather than solve it.
2. Hiding patches, those needing it can still use hidden version or download as per recommendations in docs.
3. Back to 'Needs Review' as per #48 where @_nod wants to review further.

There is still no proper explanation on how simply removing the `debounce()` call (with some other minor changes) fixes this issue.

But it might be the correct approach! Let's see, what @_nod has to say.

(After feedback, we should put this back to NW, regarding the currently failing tests).

#19 for D9.5.11

I'm struggling to reproduce this, any other cases where this happens?

@nod_ you could reproduce it through #3465484: [Info] Upstream core: Uncaught TypeError: Cannot read properties of undefined (reading 'settings') when confirmation opens, if setting up commerce isn't too much effort! 👍

Updated patch for Drupal 10

Updated patch from #62 to Drupal 10.2

Re-rolled patch from #64 for D10.3

Fixes should be in MRs

I just encountered a somewhat related error in our project in CI: ...

Error: cannot call methods on dialog prior to initialization; attempted to call method 'option'

Happens when (very) rapidly closing a dialog.

Edit: I created a dedicated issue #3472624: Error: cannot call methods on dialog prior to initialization; attempted to call method 'option' as I think it is different.
I'm surprized to see the debounce removed here though, aren't we loosing the repositioning/resizing of the dialog?

Here's the patch rerolled based on #19 for Drupal core 10.3.5 site
Attaching it here if anyone needs it

#69 works for D10.3! thanks for the patch!

MR !8892 is ready for review for D11

Same here the patch works well for me on D10.3

Patch from https://www.drupal.org/project/drupal/issues/3356667#comment-15753938 works for me on D10.2.8.

Per #67

If anybody is trying to reproduce it: For me this error happens when I am in the webforms admin page and click on "Add a webform". A modal is opened. If I now resize the window (e.g. by pressing F12 and opening the developer tools), the JavaScript error occurs. Drupal 10.4.5 and current Firefox.

Edited because LSEP character in title is no fun to handle when using the API and import the data into a neo4j database.

@jessey, can you explain why you changed the version to 10.4.x? In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies. Also mentioned on the version section of the list of issue fields documentation.

I am restoring the version and hiding all the patches.

The remaining tasks in the issue summary has 'none'. That is definitely not true. I remind everyone to keep the issue summary up to date to help everyone who is working on an issue. I updated it to say that there should be a check that this still occurs on 11.x, because most comments say this happens on D10, and then MR needs an update.

#52 works great into our Drupal 10.5.2 project.

In my case, for this to work completely (i have the jquery UI set to height: "auto") I need to keep the debounce() for the first listener and remove it for the second one:

      $(window)
        .on(
          'resize.dialogResize scroll.dialogResize',
          eventData,
          debounce(resetSize, 20),
        )
        .trigger('resize.dialogResize');
      $(document).on(
        'drupalViewportOffsetChange.dialogResize',
        eventData,
        resetSize,
      );

It is a complex project and I have many layers interfering so I do not know if this applies to a core Drupal but it would be worth to check.

- I had height set to auto
- With the patch, the first page load collapsed the dialog height - subsequent resizes or viewport changes corrected it.

Maybe that's why the 20ms debounce was introduced in the first place??

I'm still having the issue in 11.3.2. The error still appears in the console, and in order to get the modal to display correctly, I need to resize the browser window. After doing that, the modal for the media library is positioned correctly. I am able to replicate this issue with using paragraphs that have a media library field and the form field widget set to use the media library modal. I believe that the paragraphs subform is causing a shift in the layout when the subform opens, then the media library modal is triggered. I believe the dialog position logic needs to run after AJAX has had a chance to run in case of any layout shifts. I'm doing updates to the dialog.position.js in my local environment to watch for DOM changes before the resizing events occur.

I had the same issue when CKEditor was in a modal (#3577227: Fix CKEditor dialogs when displayed in a modal). The CKEditor link dialog was displayed below the modal and not visible. Somehow this caused the console error described here.
When I updated the default z-index of CKEditor, the console error went away so I don't even have to apply this patch.

Check the visibility of the elements on your projects, I know probably this may not be the only cause of the error but I hope this will help someone at least.