ping["application"]["channel"] != ping["environment"]["settings"]["update"]["channel”]

RESOLVED FIXED in Firefox 40

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: rvitillo, Assigned: Dexter)

Tracking

Trunk
mozilla41
Points:
---

Firefox Tracking Flags

(firefox40 fixed, firefox41 fixed)

Details

(Whiteboard: [uplift])

Attachments

(1 attachment)

I have seen a recent v4 ping in which the ping["application"]["channel"] and ping["environment"]["settings"]["update"]["channel”] differ. 

Is that expected?
Flags: needinfo?(gfritzsche)

Comment 1

4 years ago
What are the values? Note that there is a difference between the default (compiled-in) update channel (from nsIXULRuntime) and the actual channel, for RCs on the beta channel. And there may be differences in how we report partner-build channel modifications as well.
Flags: needinfo?(rvitillo)
The values are nightly and release for ping["application"]["channel"] and ping["environment"]["settings"]["update"]["channel”] respectively.
Flags: needinfo?(rvitillo)
Ok, that sounds like someone is testing things - i can't imagine other reasons really why a browser would have those two values at different times.
I'm monitoring this for a bit:
https://pipeline-prototype-cep.prod.mozaws.net/#plugins/filters/PrototypeSandbox-gfritzsche_ChannelDiffers

I will close this out if nothing unexpected shows up there.
(Assignee)

Comment 6

4 years ago
I had a look at this issue and run a couple of tests:

1) With a test profile, ran 39 beta and got the correct channels (environment.settings.update.channel and application.channel are the same, "beta"). Then I opened Nightly with the same profile and the channels behaved as expected ("nightly").
2) With a different test profile, ran Nightly and let Telemetry init.  Then I change the app.update.channel default (UpdateChannel.get reads the *DEFAULT* value for that pref) using |Services.prefs.getDefaultBranch(null).setCharPref("app.update.channel", "release");|

With the second test, I get what we see in the monitor (in my case, application.channel as release and environment.settings.update.channel as nightly).

That explains the nightly/release channel difference with a manual testing, since we shouldn't even be receiving pings with a "release" channel right now.

The aurora-cck-opensuse/aurora channel difference is due to partner repacking [1]: since "aurora-cck-opensuse" will still be treated as "aurora", we should exclude the partner info from the channel entry. We have the partner info in a separate section in the ping anyway (thanks Georg and Standard8 ;-) ).

[1] - https://hg.mozilla.org/mozilla-central/annotate/2c815cc65cc9/toolkit/modules/UpdateChannel.jsm#l34
(Assignee)

Comment 7

4 years ago
Created attachment 8612192 [details] [diff] [review]
bug1165304.patch
Assignee: nobody → alessio.placitelli
Status: NEW → ASSIGNED
Attachment #8612192 - Flags: review?(gfritzsche)
Attachment #8612192 - Flags: review?(gfritzsche) → review+
https://hg.mozilla.org/mozilla-central/rev/b8766738a9ba
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox41: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Side-note, it looks like someone is actually currently testing channel switching:
https://ask.mozilla.org/question/1572/restart-selfother-firefox-instance-with-restore-session-but-other-build/
status-firefox40: --- → affected
Whiteboard: [uplift]
Comment on attachment 8612192 [details] [diff] [review]
bug1165304.patch

Approval Request Comment
[Feature/regressing bug #]:
Unified Telemetry, https://wiki.mozilla.org/Unified_Telemetry
This is part of the first (main) batch of uplifts to 40 to enable shipping on that train, see bug 1120356, comment 2.
[User impact if declined]:
Data & measurement insight projects delayed or blocked with direct impact on projects depending on this.
[Describe test coverage new/current, TreeHerder]:
We have good automation coverage of the feature.
We also had manual tests of the main tasks as well as confirmation of correct behavior on Nightly for the patches here.
[Risks and why]:
Low-risk - these patches are rather isolated to Telemetry and have been on Nightly for a while with no bad reports.
We intend to track on-going data quality and other issues during the 40 aurora & beta and flip the new behavior off when it doesn't meet the requirements.
[String/UUID change made/needed]:
The only string changes were to the about:telemetry page.
We decided that we can live with missing translations on that page for a cycle as that page is not exactly user-facing.
Attachment #8612192 - Flags: approval-mozilla-aurora?
Comment on attachment 8612192 [details] [diff] [review]
bug1165304.patch

part of the unified telemetry uplift, taking it
Attachment #8612192 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.