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

  1. Write a patch
  2. Review

User interface changes

Views dialogs can be reopend

API changes

None

Files: 
CommentFileSizeAuthor
#1 2442851-1.patch1.33 KBidebr
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 87,340 pass(es). View

Comments

idebr’s picture

Status: Active » Needs review
FileSize
1.33 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 87,340 pass(es). View

The 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.

larowlan’s picture

I think the front end folks are working on removing scripts bound to both classes and ids, in favor of data attributes

idebr’s picture

Issue tags: +Usability
dawehner’s picture

+++ b/core/modules/views_ui/js/views-admin.js
@@ -311,7 +311,7 @@
-    this.$searchBox = this.$form.find('#edit-override-controls-options-search');
+    this.$searchBox = this.$form.find('.js-options-search');

What 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.

geertvd’s picture

This 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.

nod_’s picture

Patch in related issue is pretty sleek. For our purpose it's better to get rid of ID dependencies in our JS though.

dawehner’s picture

@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.

Fabianx’s picture

To 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.

idebr’s picture

This 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

nod_’s picture

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.

mgifford’s picture

Status: Needs review » Needs work

Needs re-roll.

banacan’s picture

I 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?

banacan’s picture

Actually I think this bug report better fits my issue.
Views dialogues not...

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.