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.

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 🐛 ckeditor5.dialog.fix.js throws "Uncaught TypeError: event.target.classList is undefined" in Firefox in Drupal 10 with the editor in a modal Fixed in the console, which *might* be (un)related.

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: 🐛 Overlay blocking image upload modal in Drupal 10.1 Fixed 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.

Aditi Saraf → made their first commit to this issue’s fork.

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
• 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 checked #19 patch. that patch not worked for me. few changes based on Stackoverflow 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 #28 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.)

Carlitus → changed the visibility of the branch 11.x to hidden.

Carlitus → changed the visibility of the branch 11.x to active.

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.

Grevil → changed the visibility of the branch 3356667-error-cannot-read to hidden.

Grevil → changed the visibility of the branch 11.x to hidden.

Grevil → changed the visibility of the branch 3356667-error-cannot-read to active.

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. :)

Grevil → changed the visibility of the branch 3356667-error-cannot-read to hidden.

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! 👍

Grevil → changed the visibility of the branch 3356667-undefined-settings-dialog-position to hidden.

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.

Grevil → changed the visibility of the branch 3356667-undefined-settings-dialog-position to active.

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.

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.

scott_euser → changed the visibility of the branch 3356667-undefined-settings-dialog-position-simple-fix to hidden.

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: 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'

This happens when opening and immediately closing the modal (very fast, with js). It's very easy to reproduce with some js code (click button to open modal, wait for .ui-dialog element to exist, close modal with cancel/close button).
It seems that in such cases, resetSize is called from the debounce after the jquery dialog instance has been destroyed.

This is my quick fix for now:

function resetSize(event) {
    // Ensure the UI dialog is initialized in case the dialog was closed before
    // this gets called from debounce (setTimeout).
    if (!event.data.$element.data('ui-dialog')) {
      return;
    }

    ... // original logic.

Most likely a different issue but I'm surprized to see the debounce being entirely removed in last patch #66 here.
This would fix my issue as well, but what aren't we loosing something? and is the resetSize function even still needed/relevant?

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 comment https://www.drupal.org/project/drupal/issues/3356667#comment-15753938 🐛 Error: Cannot read properties of undefined (reading 'settings')
 with dialog.position.js Needs work doesn't work for me on D10.2.8. Error is still there.

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.