Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
After closing a Views dialog it can not be reopened. The console displays an error message:
DrupalBehaviorError: attach ; viewsUiSearchOptions: this.$searchBox.val(...) is undefined
Proposed resolution
Fix the javascript error so Views dialogs can be reopend
Remaining tasks
- Write a patch
- Review
User interface changes
Views dialogs can be reopend
API changes
None
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 2442851-1.patch | 1.33 KB | idebr |
Comments
Comment #1
idebr CreditAttribution: idebr commentedThe id attributes of the input changes because the form is regenerated. By using a class instead of an id, the javascript no longer no longer triggers an error.
Comment #2
larowlanI think the front end folks are working on removing scripts bound to both classes and ids, in favor of data attributes
Comment #3
idebr CreditAttribution: idebr commentedComment #4
dawehnerWhat about simply
this.$form.find("input[name='override[controls][options_search]']")PS: I'm wondering whether some sort of regression somewhere else causes that, ... it seems to be that the trick of views to reset the ajax IDs does not work any longer,
see
ViewUI/ViewAjaxController... fixing that in the proper way is IMHO the thing we should do.Comment #5
geertvd CreditAttribution: geertvd commentedThis looks like a duplicate of #2413709: Javascript error after using jQuery UI Dialog close button in Views UI. Both have different ways to fix this issue so I'm not sure which one should stay open.
Comment #6
nod_Patch in related issue is pretty sleek. For our purpose it's better to get rid of ID dependencies in our JS though.
Comment #7
dawehner@nod_
Still something broke the code which ensures that the IDs are changed, I could imagine that this is maybe also the cause of some layout problems.
Comment #8
Wim LeersRoot cause: #1305882: drupal_html_id() considered harmful; remove ajax_html_ids to use GET (not POST) AJAX requests.
Comment #9
Fabianx CreditAttribution: Fabianx commentedTo extend some on #8, yes, lets remove the reliance on drupal_html_id() / Html::getUniqueId().
It can't hold that promise and its actually harm-ful, so if you remove the reliance on that here, that patch can go in faster ;).
What a dialog form needs is:
An identifier that is unique, but that is not changing when the ajax is rebuild, hence e.g. a hidden field with the dialog_identifier.
That is a way better way and please don't rely on $form_state either. While that exists, it is better to rely on something that is part of the form itself to replace the wrapper.
Comment #10
idebr CreditAttribution: idebr commentedThis issue was fixed by the patch in #2413709: Javascript error after using jQuery UI Dialog close button in Views UI. Leaning towards 'fixed'/'duplicate' unless anyone feels like refactoring as mentioned in #6/ #9
Comment #11
nod_Don't close this issue, the other issue is a sort of regression and we'll have to go back on it.
We designed the modal API to be in sync with the HTML5 dialog stuff. In the spec nothing is said about removing the dom element on close: https://html.spec.whatwg.org/multipage/forms.html#the-dialog-element
We don't want to add this behavior to all ajaxed dialogs. Contrib is welcome to close and remove specific dialogs explicitly but we shouldn't do that in core.
Comment #12
mgiffordNeeds re-roll.
Comment #13
banacan CreditAttribution: banacan commentedI hope I am correct in understanding what this bug report is about. Comment #10 does not apply to my case.
I'm having a problem on some views. For example, I created a duplicate of the default Taxonomy term view and I want to change settings. I am unable to access ANY of the edit modals by clicking on the setting. I can't change Filter criteria. I can't even add a filter. All of the views settings seem to be frozen. This is especially troubling since I am trying to edit a duplicate of a default core view. When I have had this problem with a custom view (one I create from the start), I will often just delete the view and re-create it.
Has there been any progress made on my/this issue?
Comment #14
banacan CreditAttribution: banacan commentedActually I think this bug report better fits my issue.
Views dialogues not...
Comment #25
quietone CreditAttribution: quietone at PreviousNext commentedThis is certainly no longer true.
If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").
Closing as outdated.