Views only able to add Attachment display

Bisected this to 0cd35ba0d0ccec12b11c5bc89809dd1712d0b03c which points to #2571673: Convert Views t() usage where it is used as an attribute value.

Debugging this further it seems that in FormBuilder::buttonWasClicked() the buttonvalue sent by the browser is "Block", but the form element value is "Add Block". As none of the submit buttons match this falls back to the first element by default, which is the attachment display.

views_ui_form_button_was_clicked() is supposed to override this behaviour for these buttons, but it has apparently stopped working.

In views_ui_form_button_was_clicked(), $element['#values'] is now an array of TranslatableMarkup objects, but we compare this to a string with the third parameter of in_array() set to TRUE, so the comparison never succeeded. Removing the third parameter and letting in_array() cast the values instead allows the buttons to work again.

This seems testable. Sorry for unRTBCing.

Unsure how to test this, as the button text is modified in JavaScript (see Drupal.behaviors.viewsUiRenderAddViewButton). drupalPostForm() needs the original button text to be able to find the correct form element. I tried this and a few variations but I could not get SimpleTest to post the form successfully:

    $this->drupalPostForm('admin/structure/views/view/test_display/edit/block_1', array(), 'Block'));

Fixing component

Let me try my luck with a test.

This makes one of the most common tasks in the views ui completely unusable.

+++ b/core/modules/views_ui/admin.inc
@@ -315,7 +315,7 @@ function views_ui_build_form_url(FormStateInterface $form_state) {
-  if ($process_input && !$form_state->getTriggeringElement() && !empty($element['#is_button']) && isset($user_input[$element['#name']]) && isset($element['#values']) && in_array($user_input[$element['#name']], $element['#values'], TRUE)) {
+  if ($process_input && !$form_state->getTriggeringElement() && !empty($element['#is_button']) && isset($user_input[$element['#name']]) && isset($element['#values']) && in_array($user_input[$element['#name']], $element['#values'])) {

Let's cast to string here. Also this is actually more complex as we need to decode HTML entities too. See #2571673: Convert Views t() usage where it is used as an attribute value

Here is a test with a little bit of explanation what we do there. Yes, its tricky, no question.

Seems there is a way to do this in drupalPostForm() alone.

+++ b/core/modules/views_ui/admin.inc
@@ -315,7 +315,7 @@ function views_ui_build_form_url(FormStateInterface $form_state) {
+  if ($process_input && !$form_state->getTriggeringElement() && !empty($element['#is_button']) && isset($user_input[$element['#name']]) && isset($element['#values']) && in_array((string) $user_input[$element['#name']], $element['#values'])) {

I think it is element['#values'] where we need to string cast. And then we can use strict typing for the in_array() again.

Ah nice, much better.

I am not sure why the TRUE parameter was there at all, seems a bit overzealous, and the original commit offers no explanation: http://cgit.drupalcode.org/views/commit/?id=651a0da

But it is easy enough to explicitly cast, see attached.

Yeah I'm pretty sure that alex is super sensitive in some of his changes.

Added a better issue summary.

I think this is ready to fly. Hit me, but I like if we break things so we end up with more test coverage.

Holy hell, great work catching this one. :\

I've seen similar casting patches necessary in e.g. Drupal Module Upgrader, and I'm growing more concerned that we might have introduced a lot of these subtle and hard-to-track-down bugs by the recent changes in lieu of SafeMarkup. :\

Looks like alexpott's feedback has been addressed, so...

Committed and pushed to 8.0.x. Thanks!