1373445 - get pretty names from extension id in the crash reports extension tab

Status: RESOLVED DUPLICATE of bug 974968

(Socorro :: General, task)

Description

[Asa Dotzler [:asa]]

Right now I have to go to DXR to look up extensions from their extension ID. It'd be super awesome if Socorro could do that for me somehow. Ideally there'd be another column in the Extensions tab that had the extension's real name.

Comment 1

[Peter Bengtsson [:peterbe]]

You mean you take that email looking string or that {hex-looking-thing}, can paste that into a DXR search or something?

What we did for bugzilla IDs is that we render just the bug IDs in the HTML, then a piece of AJAX code "scrapes" those and does a client-side fetch (via Socorro for centralized caching) so that each bug ID gets a nice tooltip (and strike-through for resolved ones). 
We could do something like that. That way, it'd be a light weight progressive enhancement without too much complexity. Feel like we could do with some guidance on that DXR query though, hint hint. Also, is there any formal public repository of Extension Id lookups we can use instead of DXR?

Comment 2

[Lonnen :lonnen]

I'd prefer avoid another scraper. Are these IDs in another place that may have an API. Maybe AMO?

Comment 3

[Peter Bengtsson [:peterbe]]

"scraper" can mean different things. What we did with bugzilla ids was not scraping since we just traversed the DOM efficiently and looked at `data-` attributes.

Comment 4

[Lonnen :lonnen]

I believe Asa is describing built in extensions that may be unlisted on AMO but are landed in the tree. They don't change their ID often (or ever, to my knowledge). We used processor transform rules to fix this one-off for the default theme: https://github.com/mozilla-services/socorro/commit/991171dcf54fbe40b247ede4a72e4b77b7c64a29

We could modify that rule into a more generic lookup table to cover unlisted extensions built into the browser.


There are other things that may install extensions, too, including SHIELD and Test Pilot. I'm not sure what to do for those.


User installed extensions can probably be retrieved from here: https://addons-server.readthedocs.io/en/latest/topics/api/internal.html#get--api-v3-addons-addon-(int-id%7Cstring-slug%7Cstring-guid)-

It may make sense to decompose this into multiple bugs if we want to address these as different cases.

Comment 5

[Peter Bengtsson [:peterbe]]

I opened the first crash I could find on Firefox 54 (https://crash-stats.mozilla.com/report/index/e3882174-7159-4419-a8da-873160170616#tab-extensions) and looked up each extension by it's ID:


>>> for ext in extensions:
...   r=requests.get('https://addons.mozilla.org/api/v3/addons/addon/{}/'.format(ext))
...   if r.status_code == 200:
...     print(ext, '\t', r.json()['name'].get('en-US'))
...   else:
...     print(':(', ext)
...
[e-mail] 	 uBlock Origin
{46551EC9-40F0-4e47-8E18-8E5CF550CFB8} 	 Stylish
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( {972ce4c6-7e08-4474-a285-3208198ce6fd}

(The last one is the "(default theme)" but even that couldn't be looked up)

So there might be better sources for this. DXR might be one. Although I still don't know how that'd be expected to be done. 

Some might be a sort of hard coded list. Like we did with the default theme.

Some silly thing that occurred to me is that almost all the email looking IDs above are self-explanatory. E.g. "[e-mail]" That's unlikely to need a more verbose name.

Comment 6

[Asa Dotzler [:asa]]

(In reply to Peter Bengtsson [:peterbe] from comment #5)
> I opened the first crash I could find on Firefox 54

You got lucky with a list of extensions that's pretty easy to digest in that report. I was looking at https://crash-stats.mozilla.com/report/index/bd09caf1-a6da-49de-aa70-79cce1170615#tab-extensions when I filed this bug. Half the extensions there are unintelligible.

Comment 7

[Peter Bengtsson [:peterbe]]

Much better outcome with those:

>>> for ext in extensions:
...   r=requests.get('https://addons.mozilla.org/api/v3/addons/addon/{}/'.format(ext))
...   if r.status_code == 200:
...     print(ext, '\t', r.json()['name'].get('en-US'))
...   else:
...     print(':(', ext)
...
{73a6fe31-595d-460b-a920-fcc0f8843232} 	 NoScript Security Suite
[e-mail] 	 HTTPS Everywhere
:( {972ce4c6-7e08-4474-a285-3208198ce6fd}
jid1-MnnxcxisBPnSXQ@jetpack 	 Privacy Badger
{12b6fdcd-4423-4276-82a3-73fdbff5f7e4} 	 Twitter App
jid1-DwRap1pOaj8qgQ@jetpack 	 Twitter Link Expander
jid0-raWjElI57dRa4jx9CCiYm5qZUQU@jetpack 	 Dictionary Pop-Up by Dictionary.com (Official)
[e-mail] 	 uBlock Origin
:( [e-mail]
:( [e-mail]
:( [e-mail]
:( [e-mail]


So, now it just boils down to this (attention willkg, lonnen):

Do we do this addons.mozilla.org lookup in the processor or the web app?

An advantage of doing it in the web app is that we could build up a cache of previously looked up extensions. So you'd be able to re-use some between crashes.

Comment 8

[Will Kahn-Greene [:willkg] ET needinfo? me]

I'm going to dupe this one to bug #974968--it's effectively the same thing.