1109757 - Add buildid and update channel to about:support and remote-troubleshooting API

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[[:Cww]]

Now that we have the remote-troubleshooting API (See bug 1079563) we realized that we don't actually have channel and beta version information in about:support which makes it hard to troubleshoot some issues. This is especially bad around release times when we might have a number of slightly out of date betas as well as release and maybe even ESR all having the same version number.

We can infer the nightly and aurora channel but this doesn't work for beta and it'd be easier if we had this data explicitly.

Can we simply add this info to the top application block?

Comment 1

[:Gijs (he/him)]

From releng:


00:58	<Gijs>	is the beta version of a build ever defined somewhere, besides an hg tag?
00:58	* Gijs can't find the commits that mark e.g. 36b4 as identifying it as "b4" anywhere in the code
00:58	<Gijs>	they just seem to tag the hg repo
00:58	<Gijs>	am I missing something?
00:59	<RyanVM|afk>	Gijs: nope, that's it
00:59	<Gijs>	RyanVM|afk: so the build itself has no idea if it's b1 or b4 or whatever?
00:59	<Gijs>	how do updates work, just by datestamps or something?
01:00	<RyanVM|afk>	the actual release builds aren't run in any visible place in automation
01:07	<nthomas>	Gijs: the update server knows the buildid of the builds
01:08	<Gijs>	nthomas: right, but the builds themselves know nothing?
01:08	* Gijs is trying to fix bug 1109757
01:08	<nthomas>	that's right
01:08	<Gijs>	"it'll be a small patch", they said
01:09	<nthomas>	I'm not sure how we'd do that
01:09	<nthomas>	the app version is 36.0 all the way through
01:09	<Gijs>	right, or whatever it is
01:10	<nthomas>	and as we look to accelerate the rate of betas we've been considering dropping the bN notation to

So I think we should expose the build ID (which implies a build date) and channel info instead. That should be sufficient to distinguish the builds, and I don't think we really have much better info.

Comment 2

[:Gijs (he/him)]

Attachment: expose update channel and buildID to about:support data gathering,

So this gets us build ID + update channel. Matt/Cww, is this enough and/or OK? Considering we might remove the beta identifiers altogether and don't currently have them available anywhere in product, that doesn't seem feasible to me (especially not for uplift to current beta, which I hear is what we want for this patch).

Comment 3

[:Gijs (he/him)]

Attachment: show update channel and build ID on about:support,

I think we should probably expose this on about:support, too. That then makes me wonder if this adds anything considering we store the last-seen buildID in prefs. I guess that pref could theoretically be locked, though (and that'd be bad). It also makes more logical sense to have the build ID with the version and name, IMO, so I would lean towards doing this... Oh, and this is a separate patch because strings and apparently we want the data bits uplifted to beta.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 8555607 [details] [diff] [review]
expose update channel and buildID to about:support data gathering,

kUpdateChannelJSM seems unnecessary (you can just inline that where used).

Comment 5

[:Gijs (he/him)]

(In reply to :Gavin Sharp [email: [e-mail]] from comment #4)
> Comment on attachment 8555607 [details] [diff] [review]
> expose update channel and buildID to about:support data gathering,
> 
> kUpdateChannelJSM seems unnecessary (you can just inline that where used).

Yes, just trying to keep line length reasonable. I find a temp var more readable than:

    data.updateChannel = Cu.import("resource://gre/modules/UpdateChannel.jsm", {})
                           .UpdateChannel.get();

but I could change it if that is preferred.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

I don't think there's any need to wrap that line.

Comment 7

[Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat )]

(is this the same bug for exposing e10s enabled into about:support api, about:support page, etc.?).

Comment 8

[:Gavin Sharp [email: [e-mail]]]

No, that's bug 1125378.

Comment 9

[[:Cww]]

I think it's fine to do something so we can at least distinguish different betas. We won't be able to report on different beta #s but we can give you a build ID where we saw a spike in problems and whoever is looking at the bug can use that instead. The problem we had before was simply that builds on different channels on the same date were hard to distinguish. This would cover that.

Thanks.

Comment 10

[[:Cww]]

Comment on attachment 8555607 [details] [diff] [review]
expose update channel and buildID to about:support data gathering,

I think this is how you say "OK" on feedback? for a patch. Poke again if I did it wrong.

Comment 11

[:Gijs (he/him)]

Attachment: expose update channel and buildID to about:support data gathering,

Gavin or Matt, can either of you formally r+ this patch (now with non-wrapped lines)? If we do want this uplifted to beta, I'd like to get this in trunk asap. :-)

Comment 12

[:Gijs (he/him)]

(In reply to [:Cww] from comment #10)
> Comment on attachment 8555607 [details] [diff] [review]
> expose update channel and buildID to about:support data gathering,
> 
> I think this is how you say "OK" on feedback? for a patch. Poke again if I
> did it wrong.

Perfect, thanks!

Comment 13

[:Gijs (he/him)]

Comment on attachment 8556527 [details] [diff] [review]
expose update channel and buildID to about:support data gathering,

This needs to modify browser_Troubleshoot.js in toolkit or it'll go orange.

Comment 14

[:Gijs (he/him)]

Attachment: expose update channel and buildID to about:support data gathering,

Now with requisite test schema changes.

Comment 15

[:Gijs (he/him)]

remote:   https://hg.mozilla.org/integration/fx-team/rev/03510eff818b
remote:   https://hg.mozilla.org/integration/fx-team/rev/782630ecde30

Comment 16

[:Gijs (he/him)]

Comment on attachment 8556561 [details] [diff] [review]
expose update channel and buildID to about:support data gathering,

Approval Request Comment
[Feature/regressing bug #]: n/a
[User impact if declined]: difficult for support data to determine which beta/aurora build the user runs
[Describe test coverage new/current, TreeHerder]: has automated tests
[Risks and why]: very low, just exposes some straightforward props on support data
[String/UUID change made/needed]: no, those are in the other (not for uplift) patch

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/03510eff818b
https://hg.mozilla.org/mozilla-central/rev/782630ecde30

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Gijs, thanks for this change!

Comment 19

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

This doesn't seem like a high priority fix, and has automated tests, so setting as "qe-verify-".

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a0200df84a44
https://hg.mozilla.org/releases/mozilla-beta/rev/f402bfa9a35e