1524531 - Aborted xhr requests should be visibly different from ongoing requests

Status: NEW

(DevTools :: Netmonitor, enhancement, P3)

Description

[torleif]

When you call xhr.abort() on an XHR request, there's (as far as I can see) no way in the Network tab to see that it has in fact been aborted. An aborted request is indistinguishable from an ongoing request.

It should somehow be visibly different.

Maybe gray/red it out like cached requests? And/Or maybe give it a special Status of 0 or A or something?

Could also be nice if the Timings would point out how long it was waiting etc and when it was cancelled. Now it says 0 on everything in the Timings app, even though the request actually was waiting for several seconds before it was aborted.

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks for the report!

I agree, there could be visual indication.

Honza

Comment 2

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Michal, is there an existing flag we could use to see that XHR has been aborted?

Honza

Comment 3

[Michal Novotny [:michal]]

I'm not familiar with the xhr object, so I don't know whether xhr.abort() does mark the object somehow. On the necko level, the request is canceled using cancel(nsresult) method. If xhr uses some specific error code to cancel the request you can check if request's status matches the error code.

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Thomas, do you think that checking xhr.status === 0 is the right way to go here?

It looks like the code base uses XMLHttpRequest_Binding::UNSENT for aborted requests.

Honza

Comment 5

[torleif]

From MDN XMLHttpRequest/abort:

The XMLHttpRequest.abort() method aborts the request if it has already been sent. When a request is aborted, its readyState is changed to XMLHttpRequest.UNSENT (0) and the request's status code is set to 0.

Comment 6

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to torleif from comment #5)

From MDN XMLHttpRequest/abort:

The XMLHttpRequest.abort() method aborts the request if it has already been sent. When a request is aborted, its readyState is changed to XMLHttpRequest.UNSENT (0) and the request's status code is set to 0.

Thanks!

Yes, this sounds promising.
Let's yet see what Thomas says.

Honza

Comment 7

[Thomas Wisniewski [:twisniewski]]

Pardon the delay here!

I think this should work, as long as the devtools don't actually show/care about the XHR until the request is actually started (since "unsent" with status 0 is also what a not-yet-sent XHR uses).

Comment 8

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Thomas Wisniewski [:twisniewski] from comment #7)

Pardon the delay here!

I think this should work, as long as the devtools don't actually show/care about the XHR until the request is actually started (since "unsent" with status 0 is also what a not-yet-sent XHR uses).

Would it be more safer to combine state with readyStaty and say that XHR is aborted when: state == 0 && readyState == 4 ?

Honza

Comment 9

[Thomas Wisniewski [:twisniewski]]

readystate will be reset to 0 / unsent after an abort, not 4 (status will also be 0). But both conditions should be checked, yes.

The potential problem is that those conditions also apply to regular unsent xhrs, so well as aborted ones.

So if it would be better to add a definite xhr.isAborted chrome-only property/method for the devtools, we could do that.

Or the devtools could perhaps add a dom listener to xhrs for the abort event, if that's more practical.