Closed Bug 1045229 Opened 6 years ago Closed 5 years ago

navigator.sendBeacon not seen in Developer Tools Console


(DevTools :: Netmonitor, defect)

31 Branch
Not set


(firefox36 fixed, firefox37 fixed, firefox38 fixed)

Firefox 38
Tracking Status
firefox36 --- fixed
firefox37 --- fixed
firefox38 --- fixed


(Reporter: dspattison, Assigned: dougt)



(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.44 Safari/537.36

Steps to reproduce:

1) navigator.sendBeacon('')
2) View Network Panel in Developer Tools Console, no entry for beacon.

Actual results:

Beacon is sent, but not shown or debuggable in the network panel.

Expected results:

Should see the Beacon under the network panel.
Component: Untriaged → Developer Tools: Netmonitor
Confirmed that this is still the case in Nightly (35.0a1 (2014-09-22)) and that the HTTP request is actually received by the remote server
Ever confirmed: true
Looks like NM__matchRequest is failing because beacons fire without an associated window.  If _logEverything is true, then you will see the beacon.  I suspect we can fix this in a number of ways, but I don't really understand why we filter anything in this function to begin with.  What's even more interesting is that I see unrelated network loads for the addon check, version check, and OCSP.  This implies that these checks just grab the top most window?  Ick.
Flags: needinfo?(dcamp)
Victor, maybe you can help here?
Flags: needinfo?(dcamp) → needinfo?(vporof)
I don't really know much about that code.
Flags: needinfo?(vporof)
(In reply to Victor Porof [:vporof][:vp] from comment #4)
> I don't really know much about that code.

I think this code was written Mihai a long time ago...  I don't know that any of us on the team now are too familiar with it. :(

Doug, it seems reasonable to tweak this function as needed.  I believe it filters by window to ensure it's finding requests for the given tab you're looking at.  Log everything mode is meant to handle the browser toolbox use case.
So, we could do a bit more here, but I am not sure if others care.

For every network load, we know exactly what caused the load.  For example, we can tell developers that a particular load came from a plugin, or media.  The different types are here:

We've done a bunch of work to make sure every network load has this info (and if it doesn't it's a serious bug).  Maybe we want to record this and also display it to the user?
Assignee: nobody → dougt
Attachment #8558838 - Flags: review?(jryans)
Comment on attachment 8558838 [details] [diff] [review]

Review of attachment 8558838 [details] [diff] [review]:

R+, please file a following we want to do more.
Attachment #8558838 - Flags: review?(jryans) → review+
Keywords: checkin-needed
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 38
Comment on attachment 8558838 [details] [diff] [review]

Approval Request Comment
[Feature/regressing bug #]:

[User impact if declined]:
web feature sendBeacon() can not be easily used by web developers using Firefox as they can not see if the feature works easily.

[Describe test coverage new/current, TreeHerder]:


[Risks and why]: 

Should be zero

[String/UUID change made/needed]:

Attachment #8558838 - Flags: approval-mozilla-beta?
Attachment #8558838 - Flags: approval-mozilla-aurora?
Attachment #8558838 - Flags: approval-mozilla-beta?
Attachment #8558838 - Flags: approval-mozilla-beta+
Attachment #8558838 - Flags: approval-mozilla-aurora?
Attachment #8558838 - Flags: approval-mozilla-aurora+
QA Whiteboard: [good first verify]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.