+thestig Not sure what could be causing this.  Though I saw our xdg-utils hasn't been updated since 2011.  Maybe it's about that time?

We don't even know if it's our copy that's failing, or the system copy. Maybe we should measure how often this specifically before trying to take any action. i.e. which state does SetAsDefaultBrowser() end up in?

1) System xdg-settings succeeded.
2) System xdg-settings failed.
3) System xdg-settings did not understand the command, bundled xdg-settings succeeded.
4) System xdg-settings did not understand the command, bundled xdg-settings failed.

For (2), there's nothing we can do. For (4), maybe we should update our xdg-utils.

Also, do we know if the spike is from users in general, or just 1 very adamant user?

Keep in mind the assumption is that users install Google Chrome Linux on systems the proper way, which means xdg-utils get installed and likely on newer distros, it is new enough to have xdg-settings and it does the right thing. Though nothing prevents someone from unpacking a .deb and use it in unintended ways. I'm a bit paranoid about that, which is why I'm hesitant to take action here.

Also, our long term goal in bug 450438 is to not ship our own xdg-utils. Someday...

This is difficult to repro without knowing which systems it affects.  wfh@ is there any way to get the OS string for these failures?

thestig@ There's not much info besides SetDefaultWebClient() is returning false, which looks like this can only happen in cases (2) or (4).
Also, I don't think it's just 1 adamant user since at one point there were 366K failures :)  But it does look like the failures are decreasing at least.

Oh and there's also this
https://bugs.chromium.org/p/chromium/issues/detail?id=578888#c16

re: #4 all we get in the UMA data is OS.version which is defined here:

https://cs.chromium.org/chromium/src/third_party/metrics_proto/system_profile.proto?sq=package:chromium&l=91

and might look something like this, for a particular user on Linux:

"4.8.0-36-generic"

I'm not sure that gives you what you want e.g. distro or anything like that.

We do have an uma metric called Linux.Distro.  Could we correlate this with CrashExitCodes.Renderer?

Try http://shortn/_r1a2Br681q let me know if you can't run it.

Thanks for writing that up wfh@

Though I don't seem to have read permissions on the db:
Error: AUTHORIZATION_ERROR: Not authorized to access table ...: permission READER denied for (TABLE) ... to user 'thomasanderson'

The metrics may be wrong, see  bug 805754 . This is instead a spike in RESULT_CODE_MISSING_DATA then?

Is it time to close this out?

Closing due to inactivity