Closed
Bug 1324692
Opened 9 years ago
Closed 9 years ago
Unable to see neither stub-attribution keys/values in Telemetry, nor associated postSigningData file
Categories
(Testing Graveyard :: WebQA, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: stephend, Unassigned)
References
Details
Attachments
(2 files)
(For now, this is the "best" place for this bug/issue, until we know what's wrong, at which point we can re-file/move, as appropriate.)
Screencast: https://drive.google.com/file/d/0B_gOai245yuJSjIwTURfUUdKRXc/view?usp=sharing
I've followed the (temporary, until bug 1320773 and any dependencies are fully fixed) instructions/steps from bug 1279291 and successfully get the test build from bug 1318456.
Unless I'm doing something wrong (quite possible, but I'm in desperate need of help, in which case), however, I don't see any stub-attribution entries in Telemetry (bug 1292360 comment 34) nor the postSigningData file mentioned in bug 1292360 comment 39.
Steps to Reproduce:
1. Using a recent Windows OS (7 or above), load https://www-demo4.allizom.org/en-US/ (I use Chrome, with the Developer panel open to the "Network" tab)
2. Click on "Download Firefox"
3. Click on/copy the https://bouncer-bouncer.stage.mozaws.net/ URL and substitute "test-stub" for "firefox-stub" in the "?product=" parameter
4. Paste/load that URL and hit Enter
5. Download, run, and finish the installation of the stub installer
6. Make sure you've set the "Show hidden files & folders" pref in your Windows OS
7. In Firefox, go to Options | Advanced | Data Choices, and check the box to enable "Share additional data (i.e., "Telemetry")
8. Restart the browser
9. Load about:telemetry and look for any "attribution" data under Environment Data :: Settings
10. Additionally, look under "C:\Users\[username]\AppData\Local\Mozilla\Firefox" (or equivalent) for postSigningData
I'm unable to find neither #9 nor #10, based on the above steps/build; help!
![]() |
||
Comment 1•9 years ago
|
||
Could manually changing "firefox-stub" to "test-stub" be invalidating the request based against the domain whitelist in bouncer? Not much clue about how that is all set up, just a thought that stick out.
Comment 2•9 years ago
|
||
Could be, I get an unaltered test-stub when I try, note the 302:
$ wget -O staging.exe "https://bouncer-bouncer.stage.mozaws.net/?product=test-stub&os=win&lang=en-US"
--2016-12-20 21:11:08-- https://bouncer-bouncer.stage.mozaws.net/?product=test-stub&os=win&lang=en-US
Resolving bouncer-bouncer.stage.mozaws.net... 52.0.57.175
Connecting to bouncer-bouncer.stage.mozaws.net|52.0.57.175|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://download-installer.cdn.mozilla.net/pub/firefox/nightly/experimental/bug1318456/test-stub.exe [following]
--2016-12-20 21:11:11-- https://download-installer.cdn.mozilla.net/pub/firefox/nightly/experimental/bug1318456/test-stub.exe
Resolving download-installer.cdn.mozilla.net... 52.84.210.156
Connecting to download-installer.cdn.mozilla.net|52.84.210.156|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 245408 (240K) [application/x-msdownload]
Saving to: ‘staging.exe’
staging.exe 100%[===============================================================================================================================================>] 239.66K 175KB/s in 1.4s
2016-12-20 21:11:13 (175 KB/s) - ‘staging.exe’ saved [245408/245408]
Also verified the SHA1 is still fda025d247855ef0b28f323fe0ffd1600ae3f13e.
![]() |
||
Comment 3•9 years ago
|
||
You should only get an altered one if the request to bouncer includes the attribution_code and attribution_sig attributes you should get from www-demo4, assuming you go there with either some utm_* params or an interesting referrer header.
Comment 4•9 years ago
|
||
agibson suggests:
https://www-demo4.allizom.org/en-US/firefox/new/?utm_source=google&utm_medium=paidsearch&utm_campaign=Brand-US-GGL-Exact&utm_term=download%20firefox&gclid=CKT-i-e11tACFYF7fgod8r4JAw
which yields (timestamp & sig specific to my request)
https://bouncer-bouncer.stage.mozaws.net/?product=firefox-stub&os=win&lang=en-US&attribution_code=source%3D%26medium%3Dreferral%26campaign%3Dfoo%26content%3D%28not+set%29%26timestamp%3D1482268537&attribution_sig=8c4df1b8632627d4e8a86cf43acf78f4c5bd088353b356be7f81fa9879d5227b
Changing firefox-stub to test-stub results in
302 https://stubattribution-default.stage.mozaws.net/?attribution_code=source%3D%26medium%3Dreferral%26campaign%3Dfoo%26content%3D%28not+set%29%26timestamp%3D1482268537&attribution_sig=8c4df1b8632627d4e8a86cf43acf78f4c5bd088353b356be7f81fa9879d5227b&lang=en-US&os=win&product=test-stub
302 https://download.mozilla.org/?lang=en-US&os=win&product=test-stub
302 https://download-installer.cdn.mozilla.net/pub/firefox/nightly/experimental/bug1318456/test-stub.exe
ie the test stub with the dummy cert but nothing added to it. Any thoughts oremj ?
Flags: needinfo?(oremj)
Reporter | ||
Comment 5•9 years ago
|
||
Clearing need-info? for Jeremy, as I've gotten this working multiple times, now, for both the "organic" and "campaign"-type flows.
A couple of fixes have landed to make this possible:
* https://github.com/mozilla-services/stubattribution/commit/5e8d5b4853acabddff25ce13c3f223695d3ac44a
* https://github.com/mozilla-services/stubattribution/commit/75d1962e5ba66e6ca676c09180f0b45506886a10
Additionally (and I'm still following up with the Telemetry team on this behavior), the attribution.* fields and their values seem to only appear after Firefox restarts; per bug 1292360 comment 41, they are sent with the "main" Telemetry ping (http://gecko.readthedocs.io/en/latest/toolkit/components/telemetry/telemetry/data/main-ping.html) so I'm unfurling that behavior/expectation, now.
Going to mark this as WORKSFORME - it's not INVALID since there were fixes, but I think that's the most-appropriate status, now.
Flags: needinfo?(oremj)
Reporter | ||
Comment 6•9 years ago
|
||
Reporter | ||
Comment 7•9 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Attachment #8821600 -
Attachment description: Screen Shot 2016-12-22 at 11.13.45 AM.png → Screenshot showing associated values for an attribution.medium type of "referral" working
Reporter | ||
Updated•9 years ago
|
Attachment #8821601 -
Attachment description: Screen Shot 2016-12-22 at 11.23.49 AM.png → Screenshot showing associated values for a working attribution.medium type of "paidsearch"
Reporter | ||
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Updated•8 years ago
|
Product: Testing → Testing Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•