Closed Bug 1109757 Opened 5 years ago Closed 5 years ago

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

Categories

(Firefox :: General, defect)

defect
Not set
Points:
2

Tracking

()

RESOLVED FIXED
Firefox 38
Iteration:
38.2 - 9 Feb
Tracking Status
firefox36 --- fixed
firefox37 --- fixed
firefox38 --- fixed

People

(Reporter: cww, Assigned: Gijs)

References

Details

Attachments

(2 files, 2 obsolete files)

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?
Points: --- → 2
Flags: qe-verify+
Flags: firefox-backlog+
Hardware: x86 → All
Version: 35 Branch → unspecified
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Iteration: --- → 38.2 - 9 Feb
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.
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).
Attachment #8555607 - Flags: review?(MattN+bmo)
Attachment #8555607 - Flags: feedback?(cww)
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.
Attachment #8555613 - Flags: review?(MattN+bmo)
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).
Attachment #8555607 - Flags: feedback+
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] 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.
I don't think there's any need to wrap that line.
(is this the same bug for exposing e10s enabled into about:support api, about:support page, etc.?).
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 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.
Attachment #8555607 - Flags: feedback?(cww) → feedback+
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. :-)
Attachment #8556527 - Flags: review?(gavin.sharp)
Attachment #8556527 - Flags: review?(MattN+bmo)
Attachment #8555607 - Attachment is obsolete: true
Attachment #8555607 - Flags: review?(MattN+bmo)
(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 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.
Attachment #8556527 - Flags: review?(gavin.sharp)
Attachment #8556527 - Flags: review?(MattN+bmo)
Now with requisite test schema changes.
Attachment #8556561 - Flags: review?(gavin.sharp)
Attachment #8556561 - Flags: review?(MattN+bmo)
Attachment #8556527 - Attachment is obsolete: true
Attachment #8556561 - Flags: review?(MattN+bmo) → review+
Attachment #8555613 - Flags: review?(MattN+bmo) → review+
Attachment #8556561 - Flags: review?(gavin.sharp)
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
Attachment #8556561 - Flags: approval-mozilla-beta?
Attachment #8556561 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/03510eff818b
https://hg.mozilla.org/mozilla-central/rev/782630ecde30
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 38
Summary: Add beta version (b1-b10) and update channel to about:support and remote-troubleshooting API → Add buildid and update channel to about:support and remote-troubleshooting API
Gijs, thanks for this change!
Attachment #8556561 - Flags: approval-mozilla-beta?
Attachment #8556561 - Flags: approval-mozilla-beta+
Attachment #8556561 - Flags: approval-mozilla-aurora?
Attachment #8556561 - Flags: approval-mozilla-aurora+
This doesn't seem like a high priority fix, and has automated tests, so setting as "qe-verify-".
Flags: qe-verify+ → qe-verify-
You need to log in before you can comment on or make changes to this bug.