1448878 - WebExtensions devtools API should send the caller fileName and lineNumber as part of the callerInfo param in the requests to the RDP WebExtensionInspectedWindowActor

Status: NEW

(WebExtensions :: Developer Tools, enhancement, P3)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

The WebExtensionInspectedWindowActor may need to emit warning or error messages, and these log messages should contains enough informations to allow a developer (or a user with enough knowledge) to identify what has actually triggered the issue.

The requests supported by this actor already include a parameter to send this informations:

- https://searchfox.org/mozilla-central/rev/003262ae12ce937950ffb8d3b0fa520d1cc38bff/devtools/shared/specs/webextension-inspected-window.js#22-30,101,107

But we don't currently collect the original fileName and lineNumber of the caller (from the child extension process where the API call is originated from), and so the callerInfo.url property is currently set to the extension base URL and the lineNumber is not set:

- https://searchfox.org/mozilla-central/rev/003262ae12ce937950ffb8d3b0fa520d1cc38bff/browser/components/extensions/ext-devtools-inspectedWindow.js#18-23

- https://searchfox.org/mozilla-central/rev/003262ae12ce937950ffb8d3b0fa520d1cc38bff/browser/components/extensions/ext-devtools-panels.js#512-517

We should add an implementation of the related API methods in ext-c-devtools-inspectedWindow.js and ext-c-devtools-panels.js, which could collect this information and send them to the main process alongside to the rest of the API call parameters (or make it part of the informations sent from the "proxy" wrapper that the WebExtensions internals automatically generate based on the API schema).

Comment 1

[Kris Maglione [:kmag]]

I suggest that you do something similar to what we did in bug 1441333. Please keep in mind, though, that collecting this information is relatively expensive. If you can re-use the saved frame that we collect when we handle an asynchronous API call, that would be ideal. And if you can keep it in SavedFrame form until the moment when you actually need it, that's even better. SavedFrames automatically manage caching and merging any extant SavedFrame objects for the same location, which means avoiding a bunch of unnecessary, duplicate object/string allocations.