Open Bug 1193811 Opened 9 years ago Updated 2 years ago

Show a message to the user that network monitor doesn't work with file:/// protocols

Categories

(DevTools :: Netmonitor, enhancement, P3)

enhancement

Tracking

(firefox43 affected)

Tracking Status
firefox43 --- affected

People

(Reporter: sole, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: DevAdvocacy, Whiteboard: [polish-backlog][difficulty=medium][DevRel:P2])

Right now, if I try to debug the network requests originating from a file in the local filesystem (i.e. using a file:///) the only thing I get is the "perform a request or press reload to see detailed information about network activity". I can keep pressing Reload for the whole remainder of the day but it won't show me anything because it's a file:/// and the panel just doesn't track those. My suggestion is that we should do a bit of hand holding here and tell the user that these requests are not monitored (aren't them?) and they should open a local server or something of that sort instead. At least tell them something! I though the monitor was broken since I'm using Nightly and who knows what might have happened :-) Using nightly 2015-08-12
Keywords: DevAdvocacy
Nice - adding to the backlog and needinfo'ing Brian. Brian, can you estimate difficulty= here? Is this a good first/next bug?
Flags: needinfo?(bgrinstead)
Priority: -- → P2
Whiteboard: [polish-backlog]
(In reply to Jeff Griffiths (:canuckistani) from comment #1) > Nice - adding to the backlog and needinfo'ing Brian. > > Brian, can you estimate difficulty= here? Is this a good first/next bug? Note this looks like it also affects internal pages like about:preferences. Given a URI we could detect anything loaded from the filesystem with code like this (which is used for the browser identity popup): https://dxr.mozilla.org/mozilla-central/rev/7649ffe28b67aa2dad0f67ea01500c0ff91b2bac/browser/base/content/browser.js#7141. Then to modify the view and show an alternate message really shouldn't be that hard and could probably be tackled with a mentor. But first.. forwarding the needinfo to Victor to see if there may be a way where we can actually show the requests.
Flags: needinfo?(bgrinstead) → needinfo?(vporof)
AFAIK we don't care about file:// because they're not served over the network. A workaround for now for any user would be to simply create a simple localhost server. Regarding on the backend implementation, I really don't remember much about how we handle those, and whether or not we filter those automatically or on purpose. I suspect panos would be a better person to ask. If we can't show those requests, it'd indeed be nice to let the users know we only care about network activity.
Flags: needinfo?(vporof)
Whiteboard: [polish-backlog] → [polish-backlog][difficulty=medium]
Pinging Panos w/r/t comment #3
Flags: needinfo?(past)
We already have some support (c.f. the "FileActivity" listener) to record file:// requests that the console already uses. The main issue with the netmonitor is that the progress listener API we are using doesn't provide us with the detailed information that the netmonitor needs to display. Bug 1000540 is about doing this work, but also see bug 982606 comment 0 for a similar issue affecting b2g. If we can't get anyone to work on bug 1000540 soon, then it certainly makes sense to show a message in this bug. I'm hopeful however that we could figure out a simple way to deal with network events with missing data, like we do with cached HTTP requests.
Flags: needinfo?(past)
Whiteboard: [polish-backlog][difficulty=medium] → [polish-backlog][difficulty=medium][DevRel:P2]
Product: Firefox → DevTools
Type: defect → enhancement
Priority: P2 → P3
Severity: normal → S3
See Also: → 1000540
You need to log in before you can comment on or make changes to this bug.