Fix contextual links disappear intermittently leading to console errors

I realise that this results in contextual links not showing, but the stack trace seems to suggest settings tray module

Contextual links won't show if JavaScript execution halts due to an error, so I'm not convinced this is acrual contextual module at fault, rather that it's a symptom of a JS execution error

The error is coming from https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/setti...

It's not checking the element is found before attempting to read it's ID

You are right, thank you for highlighting the issue, and uninstalling settings_tray. has fixed the problem. I initially thought it was a Contextual links issue because of the full trace error.
a

Reverting this issue seems to fix it https://www.drupal.org/project/drupal/issues/3238868 📌 Refactor some uses of the jQuery parents function to use vanillaJS Fixed

Here's the problem: not every instance.element has contextual links. Previously, jQuery would tolerate calling attr('id') on null and return undefined. However, vanilla JS does not behave the same way; it throws an error, and halts the contextual links, as you mentioned.

A couple of elements that don't have contextual links
" />

There is also some contrib/custom.

Changing variable name.

MR should be pointed as 11.x as current development branch.

Think we need to figure out why that value is null vs just putting a check in. May help determine what/if kind of test coverage we need.

Same thing after updating to Drupal 10.3.1, I have to keep flushing caches several times as 1 one contextual config gear appears at a time.

I implemented the patch in #8 and that works for me.

Not sure the proposed solution matches what's in the MR. If my javascript is off and it does line up feel free to put back in review.

@smustgrave FYI:

instance.options.data.dialogOptions.settingsTrayActiveEditableId = closestSettingsTray?.id;

is the shorthand for

instance.options.data.dialogOptions.settingsTrayActiveEditableId = closestSettingsTray ? closestSettingsTray.id : undefined;

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operat...
Browser compatibility is also fine.

Of course I'm not sure if the proposed resolution is acceptable at all, as it doesn't really fix the root cause.

Re #4 @larowlan FYI: We don't have settings tray module enabled and since 10.3 run into

Uncaught TypeError: closestSettingsTray is null

I think we should fix this asap.

Agree we should try to fix this asap - do we have steps to reproduce though?

@larowlan in our case we just have to open layout builder for a node type, e.g.
/admin/structure/types/manage/page/display/default/layout

The resulting message is a bit different from the issue summary, but I think has the same cause:

Uncaught TypeError: closestSettingsTray is null
    prepareAjaxLinks https://www.example.de/core/modules/settings_tray/js/settings_tray.js?v=10.3.1:171
    prepareAjaxLinks https://www.example.de/core/modules/settings_tray/js/settings_tray.js?v=10.3.1:162
    <anonymous> https://www.example.de/core/modules/settings_tray/js/settings_tray.js?v=10.3.1:191
    jQuery 7
    initContextual https://www.example.de/core/modules/contextual/js/contextual.js?v=10.3.1:136
    attach https://www.example.de/core/modules/contextual/js/contextual.js?v=10.3.1:198

Layout builder can't be really used any more due to the missing contextual links.

Ha, I finally found a way to be able to edit layout_builder layouts again! Simply uninstall settings_tray!
We never really used it and after uninstalling settings_tray, layout_builder works again and the errors are gone (which is not really unexpected ;))

While none of the patches seem to help/fix the root cause, the comment from @Anybody about settings_tray module helped. I uninstalled it temporarily and I was able to edit the layout. Thanks!

manibharathi ezhimalai ravi → changed the visibility of the branch 3458067-contextual-links-disappear-11.x to hidden.

Hi,
Issue able to reproduce in the Drupal10.3.x.
MR !8585 has been fixing the issue for Drupal 10.3.x.

Issue not able to reproduce in the Drupal 11.x. Please find the evidence from the Drupal11.x.

Steps to Reproduce the issue:

1. Install Drupal 10.3.x
2. Enable the Settings Tray and Layout builder module
3. Enable the layout builder for any content type
4. Add the two different inline blocks in the layout settings
5. Check in the console and observe the issue.

Since this issue is already reviewed we can move to the RTBC.

Anyone else able to reproduce on 11.x?

Same problem here on Drupal 10.3.2 + enabled settings tray + enabled layout builder:

Uncaught TypeError: closestSettingsTray is null
    prepareAjaxLinks http://tc4.top-cloud/core/modules/settings_tray/js/settings_tray.js?v=10.3.2:171
    prepareAjaxLinks http://tc4.top-cloud/core/modules/settings_tray/js/settings_tray.js?v=10.3.2:162
    <anonymous> http://tc4.top-cloud/core/modules/settings_tray/js/settings_tray.js?v=10.3.2:191
    jQuery 7
    initContextual http://tc4.top-cloud/core/modules/contextual/js/contextual.js?v=10.3.2:136
    attach http://tc4.top-cloud/core/modules/contextual/js/contextual.js?v=10.3.2:198
    setTimeout handler*attach/< http://tc4.top-cloud/core/modules/contextual/js/contextual.js?v=10.3.2:197
    attach http://tc4.top-cloud/core/modules/contextual/js/contextual.js?v=10.3.2:189
    attachBehaviors http://tc4.top-cloud/core/misc/drupal.js?v=10.3.2:166
    attachBehaviors http://tc4.top-cloud/core/misc/drupal.js?v=10.3.2:162
    insert http://tc4.top-cloud/core/misc/ajax.js?v=10.3.2:1389
    jQuery 2
    insert http://tc4.top-cloud/core/misc/ajax.js?v=10.3.2:1381
    commandExecutionQueue http://tc4.top-cloud/core/misc/ajax.js?v=10.3.2:1046
    promise callback*Drupal.Ajax.prototype.commandExecutionQueue/< http://tc4.top-cloud/core/misc/ajax.js?v=10.3.2:1039
    commandExecutionQueue http://tc4.top-cloud/core/misc/ajax.js?v=10.3.2:1036
    success http://tc4.top-cloud/core/misc/ajax.js?v=10.3.2:1095
    processReplacement http://tc4.top-cloud/core/modules/big_pipe/js/big_pipe.js?v=10.3.2:84
    checkMutationAndProcess http://tc4.top-cloud/core/modules/big_pipe/js/big_pipe.js?v=10.3.2:110
    processMutations http://tc4.top-cloud/core/modules/big_pipe/js/big_pipe.js?v=10.3.2:134
    processMutations http://tc4.top-cloud/core/modules/big_pipe/js/big_pipe.js?v=10.3.2:133
    MutationCallback* http://tc4.top-cloud/core/modules/big_pipe/js/big_pipe.js?v=10.3.2:150
    <anonymous> http://tc4.top-cloud/core/modules/big_pipe/js/big_pipe.js?v=10.3.2:184

Seems like a small change but should we have test coverage for this?

@smustgrave, I don't believe we need test coverage for this, as the main issue is that certain components from modules disrupt core functionality. I don't think this should be the case.

For instance, consider the moderation_sidebar module from #7 comment, where the element possesses the attribute data-dialog-renderer but lacks a contextual link.

the patch from #7 is working fine for me with drupal 10.3.5. this is major issue for editor after 10.3 upgrade. This need to be fixed asap. But as per comment in #19 "Of course I'm not sure if the proposed resolution is acceptable at all, as it doesn't really fix the root cause." which gives us bit hesitation in apply the patch from #7 for our project and uninstalling settings_tray also might impact the existing editing experience for editors.