Closed Bug 1669545 Opened 4 years ago Closed 4 years ago

Show internal blocked reason instead of only "Blocked" when there is no valuable blocking reason

Categories

(DevTools :: Netmonitor, enhancement)

enhancement

Tracking

(firefox83 fixed)

RESOLVED FIXED
83 Branch
Tracking Status
firefox83 --- fixed

People

(Reporter: ochameau, Assigned: ochameau)

References

(Regressed 1 open bug)

Details

Attachments

(1 file)

The following code, listening to http-on-stop-request always assumes the request is blocked if httpActivity.owner isn't set. But in the current state of the netmonitor, there is a couple of cases where the request is fully complete and we receive this http-on-stop event.

  _httpStopRequest: function(subject, topic) {
    ...
    const httpActivity = this.createOrGetActivityObject(channel);
    if (httpActivity.owner) {
      // Try extracting server timings. Note that they will be sent to the client
      // in the `_onTransactionClose` method together with network event timings.
      httpActivity.owner.addSeverTimings(serverTimings);
    } else {
      // If the owner isn't set we need to create the network event and send
      // it to the client. This happens in case where the request has been
      // blocked (e.g. CORS) and "http-on-stop-request" is the first notification.
      this._createNetworkEvent(subject, {
        blockedReason: reason,
        blockingExtension: id,
      });

The issue here comes from the else branch, which always assumes the request is blocked.

It is quite easy to reproduce with fission and navigating between two distinct origins. A brand new NetworkObserver is instantiated for each new navigation. And by the time the NetworkObserver start listening a few requests already started, so that we only receive the http-on-stop event. But all the requests are fully valid and complete, there only miss the owner attribute which is set by an event fired ealier, but missed by the new NetworkObserver.

Also, this code highlight another issue. A few requests failed, but we aren't receiving any particular blocking reason. reason is set to 0. But the request failed for some reason. We should try to communicate this reason. channel.status contains an error code. This can be cryptic, but it would certainly help us and platform developer understand netmonitor limitations/races!

Assignee: nobody → poirot.alex
Status: NEW → ASSIGNED
Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b8c0746ee199
[devtools] Print internal error codes instead of only "Blocked" when there is not explicit blocking reason. r=Honza
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch
Regressions: 1672960
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: