Opened 14 years ago
Last modified 6 years 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: | needs-testing needs-refresh |
Focuses: | administration | 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)
Change History (11)
#2
@
14 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?
#4
@
14 years ago
- Milestone changed from 3.1 to Future Release
You're right, not a regression. Punting.
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
7 years ago
#8
@
7 years ago
'Lose your changes' confirmation for quick edit and bulk edit before an AJAX action.
+1
Really rough idea that needs a lot of copy help:
You’re about to move away from Quick Edit and lose your changes. Are you sure you want to do this?
there's a really big patch for that