[wp-trac] [WordPress Trac] #35501: Dashboard page: incorrect work of "Activity" group box bottom counters

[WordPress Trac]

#35501: Dashboard page: incorrect work of "Activity" group box bottom counters
--------------------------+-----------------------------------------
 Reporter:  antonrinas    |       Owner:  adamsilverstein
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  4.6
Component:  Comments      |     Version:  4.4.1
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  javascript, administration
--------------------------+-----------------------------------------
Changes (by vagios):

 * keywords:  needs-patch => has-patch


Comment:

 Thank you all for reviewing the patch.

 Replying to [comment:13 azaozz]:
 > Much more common problem with the patch is when the network is slow(er).
 The users will not be able to quickly approve/unapprove/delete comments,
 etc. They will have to wait for the previous AJAX request to complete
 which can be very tedious/slow.

 In 35501.5 I tried a slightly different approach,
 - The xhr objects are now saved in an xhrs object using the corresponding
 comment as identifier. e.g

 {{{
 xhrs = {
     comment-26: { xhr object },
     comment-42: { xhr object }
 }
 }}}

 - An AJAX request will be aborted only if there is already an unfinished
 AJAX request from the same comment.

 - Added some code at the beginning of `ajaxDel` and `ajaxDim` to delete
 finished requests from xhrs.

 - Clicking the 'Undo' button (after a trash/spam action) while the
 trash/spam request is still going doesn't create a new request but changes
 the DOM. To avoid this I added code to abort the request in `delBefore`
 (inside edit-comments.js), and to be able to do it I pass xhrs into the
 settings object. Semantically it doesn't seem very good.

 Replying to [comment:12 adamsilverstein]:
 > We could add a timeout catch for failures and reset the xhr object, but
 I think the added complexity isn't worth the effort.
 Indeed, we could catch timeouts and update the DOM (because it changes
 before the request finishes). I can try that but I would like to agree
 first on a solution for the previous issue because it seems more common.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35501#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform