Closed
Bug 1373445
Opened 7 years ago
Closed 3 years ago
get pretty names from extension id in the crash reports extension tab
Categories
(Socorro :: General, task)
Socorro
General
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 974968
People
(Reporter: asa, Unassigned)
Details
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•7 years ago
|
||
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•7 years ago
|
||
I'd prefer avoid another scraper. Are these IDs in another place that may have an API. Maybe AMO?
Comment 3•7 years ago
|
||
"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•7 years ago
|
||
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•7 years ago
|
||
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) ... uBlock0@raymondhill.net uBlock Origin {46551EC9-40F0-4e47-8E18-8E5CF550CFB8} Stylish :( activity-stream@mozilla.org :( aushelper@mozilla.org :( e10srollout@mozilla.org :( firefox@getpocket.com :( flyweb@mozilla.org :( formautofill@mozilla.org :( presentation@mozilla.org :( screenshots@mozilla.org :( shield-recipe-client@mozilla.org :( webcompat-reporter@mozilla.org :( webcompat@mozilla.org :( onboarding@mozilla.org :( clicktoplay-rollout@mozilla.org :( followonsearch@mozilla.com :( {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. "screenshots@mozilla.org" That's unlikely to need a more verbose name.
Reporter | ||
Comment 6•7 years ago
|
||
(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•7 years ago
|
||
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 https-everywhere@eff.org 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) uBlock0@raymondhill.net uBlock Origin :( aushelper@mozilla.org :( e10srollout@mozilla.org :( firefox@getpocket.com :( webcompat@mozilla.org 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•3 years ago
|
||
I'm going to dupe this one to bug #974968--it's effectively the same thing.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•