Hi,
When using the theme as admin theme, there is a bug in forms which use the table drag element, for example the manage form display page.
When the user tries to hide a field by clicking on the widget dropdown, the process is interrupted and the field is disabled without saving the change as you see in the screenshot below:
Manage form display for article node type

The bug is caused by the theme which transforms input 'edit-refresh':
Original:
<input class="visually-hidden button js-form-submit form-submit" data-drupal-selector="edit-refresh" type="submit" id="edit-refresh" name="op" value="Refresh">

Button:
<button class="visually-hidden button js-form-submit form-submit btn-default btn" data-drupal-selector="edit-refresh" type="submit" id="edit-refresh" name="op" value="Refresh">Refresh</button>

Thus the following code in field_ui.js doesn't work:

    /**
     * Triggers Ajax refresh of selected rows.
     *
     * The 'format type' selects can trigger a series of changes in child rows.
     * The #ajax behavior is therefore not attached directly to the selects, but
     * triggered manually through a hidden #ajax 'Refresh' button.
     *
     * @param {object} rows
     *   A hash object, whose keys are the names of the rows to refresh (they
     *   will receive the 'ajax-new-content' effect on the server side), and
     *   whose values are the DOM element in the row that should get an Ajax
     *   throbber.
     */
    AJAXRefreshRows: function (rows) {
        //other code
        $('input[data-drupal-selector="edit-refresh"]').trigger('mousedown'); //Line 232
       //other code
    }

Thanks

Comments

Ismail Cherri created an issue. See original summary.

ismail cherri’s picture

Here is quick fix for the issue.

markhalliwell’s picture

Version: 8.x-3.0-rc1 » 8.x-3.x-dev
Priority: Major » Normal
Status: Active » Needs work

Technically, this is a bug with core. It shouldn't be targeting input, but rather :input (which includes buttons).

Regardless, if this "fix" is going to be in this base theme, then it needs to override the JS that targets it, not putting a special use case in PHP which ultimately wouldn't work because it's targeting an ID that can technically change during AJAX request.

markhalliwell’s picture

Actually, considering that this base theme is primarily focused for front-end implementation (not administrative areas), I'm just going to close this as there are existing core issues that should ultimately fix this.

gaëlg’s picture

I needed to reroll #2 against 3.11 for a project quick fix. Here's the patch in case it can help someone else.

gaëlg’s picture

Whoops, the same but correct.

markhalliwell’s picture