Double clicking update on list table inline edit removes row from dom

[mt8.biz]

Steps to reproduce:
Open "Quick Edit" -> Save the category(or tag) by double-click on save-button. ( or press twice ).

Expected behaviour:
Save the category(or tag) , and refresh the table-row.

Actual behaviour:
Save the category(or tag), But disappear the table-row.

[knutsp]

Confirmed for 3.8-alpha. Only happens when double clicking.

[c3mdigital]

I can reproduce in 3.6.1 On all List Tables that have quick edit. This is a result of how closures work in javascript and can be explained better here ​http://stackoverflow.com/a/10152046.

Maybe disabling the update button when the first click event fires?

[helen]

#25573 was marked as a duplicate.

[helen]

#25606 was marked as a duplicate.

[helen]

Closed #25573 (posts) and #25606 (comments), as this ticket seems to have attracted more eyes. Suggest working on a generalized solution, even if it has to go into multiple files.

Related: #25627

[shanept]

Changes to inline-edit-tax.js and inline-edit-post.js.

[mt8.biz]

Thanks For Manage Tickets. ( And Patch To English. )

Do you have problems with my patch?

[mt8.biz]

Changes to edit-comments.js .

I was referring to the patch of shanept.

Thanks.

[mt8.biz]

some fix.

[afercia]

I'd propose a new approach, similar to what is used in heartbeat.js (actually heartbeat.js has two ways to handle this). Basically aborting the AJAX request if any previous one has not completed yet would solve the double click (and double Enter) issue. The same approach can be used to fix #12769.

The attached patch is for testing only for now, and focuses only on inline-edit-post.js. If OK, the same thing should be done for inline-edit-tax.js. Have to check comments yet.

Any feedback would be greatly appreciated, cc @azaozz :)

Note: the simpler way to reproduce this is:

• Quick Edit a post
• place the cursor on any input field or textarea, focus a select or check a checkbox
• quickly press "Enter" twice
• after saving, the Quick Edit form closes and the table row disappears

[ericlewis]

Replying to c3mdigital:

Maybe disabling the update button when the first click event fires?

This sounds like a good approach, as this is something we already do in other cases (e.g. Publish button on the Edit Post page is disabled after click and during autosaves).

[afercia]

Disabling buttons is problematic for keyboard users since the buttons will be focused and then disabled, causing a focus loss.

[ericlewis]

Replying to afercia:

Disabling buttons is problematic for keyboard users since the buttons will be focused and then disabled, causing a focus loss.

Good to know! Should button disabling be considered an anti-pattern for that reason?

[afercia]

Replying to ericlewis:

Good to know! Should button disabling be considered an anti-pattern for that reason?

It always depends, case by case. But when disabling, hiding, removing from the DOM, a focused element then focus should be moved to the most logical place. Better: avoid a focus loss in the first place :)
Also, the Quick Edit form can be submitted pressing Enter on any field (also the textarea, select, checkboxes) so I'm not sure disabling the button would really solve the issue.

[azaozz]

25696.patch is a good start. Think we will need to abort the request when the users click Cancel so if they click on another Quick Edit it won't block it.

We also may need better "busy" indication. Clicking on another Quick Edit while the request hasn't been completed yet or had some sort of error is frustrating: nothing happens. Wondering if we should be showing wait or progress cursor?

[azaozz]

In 25696.2.patch: also add xhr.abort() when the user clicks Cancel.

[afercia]

Refreshed patch, taking care also of Terms and Comments. Some notes:

• when saving maybe it should just return false instead of using xhr.abort()
• should users be allowed to open a new Quick Edit form while a previous request has not completed yet? this would be easy to restore, not sure if safe
• removed the toggle function, it was used to open the form on double click, seems no more used since [9439] and removed in [9726] unless I'm missing something
• the parameter passed to save() and edit() is always a DOM object so calling it id is a bit confusing

Clicking on another Quick Edit while the request hasn't been completed yet or had some sort of error is frustrating: nothing happens.

Yep, see point 2. Currently, clicking to open a new form won't do anything, see below:

Theoretically, the whole thing could be refactored in order to allow a row to be updated "in the background" when it's closed because users clicked on a new Quick Edit link. Not sure it would be so safe and easy to implement :)

[afercia]

To recap: the patch still applies cleanly, needs a decision about this point:

should users be allowed to open a new Quick Edit form while a previous request has not completed yet?

in response to:

Clicking on another Quick Edit while the request hasn't been completed yet or had some sort of error is frustrating: nothing happens.

Note: this should fix also #12769.

[chriscct7]

Punted per discussion in slack: ​https://wordpress.slack.com/archives/core/p1457564815004820

[SirLouen]

Reproduction Report

Description

✅ This report validates that the issue can be reproduced.

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 137.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-One 2.5
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Test Steps

• Go to Posts > Categories
• Create a Category
• Click on Quick Edit for that category
• Double-click on the Update Category button
• 🐞 The category disappears

Actual Results

1. ✅ Error condition occurs (reproduced).

Additional Notes

• @afercia it seems that your last patch is not applying any more, if you are still around can you check it when possible?