Closed Bug 1638471 Opened 5 months ago Closed 4 months ago

Show user-facing addon name instead of guid for blocked requests

Categories

(DevTools :: Netmonitor, enhancement, P3)

enhancement

Tracking

(firefox78 fixed)

RESOLVED FIXED
Firefox 78
Tracking Status
firefox78 --- fixed

People

(Reporter: Harald, Assigned: Honza)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Right now addons are displayed using the internal guid, but we should show the user-facing addon name from the manifest.

Instead of showing "uBlock0@raymondhill.net" it should be "uBlock Origin"

Summary: Show addon name for blocked requests → Show user-facing addon name instead of guid for blocked requests
Blocks: 1638476
No longer blocks: 1638476

Luca, should we just use 'policy.name' instead of 'policy.id' on this line:
https://searchfox.org/mozilla-central/rev/09b8072a543c145de2dc9bb76eddddd4a6c09adc/toolkit/components/extensions/webrequest/WebRequest.jsm#928

...or could DevTools get extension name from ID using an API?

Honza

Flags: needinfo?(lgreco)

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #1)

Luca, should we just use 'policy.name' instead of 'policy.id' on this line:
https://searchfox.org/mozilla-central/rev/09b8072a543c145de2dc9bb76eddddd4a6c09adc/toolkit/components/extensions/webrequest/WebRequest.jsm#928

...or could DevTools get extension name from ID using an API?

yes, we could as well turn the extension id into a name from network-observer.js using something like:

const extensionPolicy = WebExtensionPolicy.getByID(extID);
const extName = extensionPolicy.name;

we are already doing something similar for the debugger panel in devtools/server/actors/source.js here (but to get the extension name from the moz-extension url in that case).

If we resort to this, it may be reasonable to use a WeakMap<WebExtensionPolicy -> string> to avoid doing that for every single blocked resource.

One caveat in doing that from network-observer.js is that in the global of the devtools modules the WebExtensionPolicy global isn't available by default like in jsm modules, and so we would have to retrieve it explicitly using something like Cu.getGlobalForObject(Cu).WebExtensionPolicy, like we are doing in the devtools/server/actors/source.js here.

I'm needinfo Shane, to hear his opinion, e.g. if he would actually prefer to do that in WebRequest.jsm.

Flags: needinfo?(lgreco) → needinfo?(mixedpuppy)

The extension ID was used here specifically because if more extension info was desired, you would not be able to get to it (100% reliably) from the extension name. As Luca described, you can use the policy to get what you need.

Flags: needinfo?(mixedpuppy)
Assignee: nobody → odvarko
Status: NEW → ASSIGNED
Pushed by jodvarko@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ec7aebcb24cb
imported patch ext-name.diff r=bomsy
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 78
You need to log in before you can comment on or make changes to this bug.