Visibility in Developer Tools?

[nicjansma]

Hi!

I know the use-cases for PendingBeacon may be slightly different from XHR and sendBeacon() calls, but I was wondering if there was a plan to expose PendingBeacon requests within developer tools?

I realize this is probably outside of the direct scope of the spec (as each UA's developer tools may choose to deal with this differently), but I'm concerned about the debugability of the API if it's not easily visible in dev tools.

As far as I can tell today, PendingBeacon requests are not showing up in Chrome's Network tab. As I've started to play around with the API for its use in RUM, I think this could make the usability of the API more challenging. I've had to debug via a proxy to verify my usage of it, e.g. with Fiddler below:

I know the "timeout" aspects of this API play out a little differently than if a developer calls XHR or sendBeacon(), as the later (in practice) usually get sent immediately and show up directly in the Network tab. So as I'm debugging my RUM pipeline, I can easily see the XHR/sendBeacon requests go out and verify their payloads and response codes in the Network tab.

A PendingBeacon may get sent "later" depending on its timeout and backgroundTimeout, but I would ideally still like to see those associated with the page as far as the Network tab reports them. For example, with backgroundTimeout if I had the "Persist" setting enabled in the Network tab, as I navigated to the next page, I'd hope to see the beacon still be reported as being sent after that timeout. With timeout:0 I'd love to see it show up right away.

Specifically as a RUM provider, I see the benefit of showing the beacons in the Network tab for a few reasons:

• As a developer implementing this API, I did not see an immediate feedback when calling new PendingGetBeacon() in the console or initially trying the API on a test website. I had to use a proxy to verify the requests were going out
• As a RUM provider, we often have to debug our RUM scripts and pipeline on customer websites. A key part is verifying our JavaScript gets loaded, and the beacon gets sent, its payload is correct, and the response code is 2xx. We debug countless issues where seeing the requests directly in Dev Tools has been an essential triage tool.
  • Often, we'll ask our customers for screenshots of problems (with Dev Tools open) -- requiring a proxy to get that information could be a non-starter

Anyway, I'm not sure with the Origin Trial if this was just not implemented yet or if there was a concern about surfacing in Dev Tools, but my vote would be to find a way to include in the Network pane if possible.

[nicjansma]

Ah I now see in the explainer:

What's not supported:
...
Beacon requests are not yet observable in Chrome DevTools.

So hope that it'll come at some point!

[fergald]

Yes, it's a known issue and we haven't really started thinking about it yet but as you say, it's not really for the spec.

I think there's also currently no way to debug Reporting-API requests, so maybe this is similar (if we allow retries in the background/later it is).

[nicjansma]

Since fetchLater() is now based on Fetch, it looks like both immediate (activateAfter: 0) and deferred/delayed (activateAfter: nnnnnn) beacons both show up in Network panel in Chrome.

This is great for debug-ability, so I'll close this out.

[cthae]

How is this not seen as a security issue?