WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 2 months ago

#15981 assigned defect (bug)

Quick edit (and other actions) need to cancel AJAX actions

Reported by: nacin Owned by: garyc40
Milestone: Future Release Priority: low
Severity: normal Version: 3.1
Component: Quick/Bulk Edit Keywords: ux-feedback has-patch needs-testing
Focuses: Cc:

Description

Right after you click to paginate, sort or try to search something, you may be inclined to click another link on the page. This happens often when I'm browsing, and on a server with a relatively slow AJAX round trip, it can happen quite commonly.

Problem: If you open Quick Edit, then the ajax results should noop. There might be other actions, but this one in particular does not lead to another page (which obviously would kill the ajax).

The reverse is also an issue. You can search, paginate, or sort when Quick Edit is open, and you lose your edit. This might be bad when quick editing a comment, as you could be losing actual content. Searching and paginating might be explicit actions, but it's not difficult to accidentally click a th and trigger a sort, especially if the first row's quick edit (or bulk edit) is open.

I'm not sure what to do here, other than a JS popup for any time a Quick/Bulk Edit is open, asking you if you want to lose your changes.

So again, two things:

  • Kill the AJAX action if Quick Edit is opened. I would consider this lower priority.
  • 'Lose your changes' confirmation for quick edit and bulk edit before an AJAX action. (We can probably fire the AJAX action and trigger the alert simultaneously, but delay processing the results until the confirm() is true.)

Attachments (1)

garyc40-15981.patch (8.7 KB) - added by garyc40 3 years ago.
there's a really big patch for that

Download all attachments as: .zip

Change History (6)

comment:1 garyc403 years ago

  • Owner set to garyc40
  • Status changed from new to assigned

garyc403 years ago

there's a really big patch for that

comment:2 garyc403 years ago

Attached a patch with lots of reds and greens. It's complicated because I agree with nacin that it's better UX to delay the processing of the AJAX responses (as well as delaying the change in table headers when sorting) instead of stopping the AJAX requests altogether to display the confirm dialog.

This is a big patch. And it's not a regression either, so I'm thinking whether we should mark this as 3.2-early instead?

comment:3 garyc403 years ago

  • Keywords has-patch needs-testing added

comment:4 nacin3 years ago

  • Milestone changed from 3.1 to Future Release

You're right, not a regression. Punting.

comment:5 nacin2 months ago

  • Component changed from Administration to Quick/Bulk Edit
Note: See TracTickets for help on using tickets.