Closed
Bug 1425348
Opened 6 years ago
Closed 6 years ago
Limit recording engagement scalars to parent process
Categories
(Toolkit :: Telemetry, enhancement, P4)
Toolkit
Telemetry
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox59 | --- | affected |
People
(Reporter: gfritzsche, Unassigned, Mentored)
References
(Blocks 1 open bug)
Details
(Whiteboard: [good first bug] [lang=js])
Bug 1423446 shows that some engagement scalars are not recorded in the content process: "SCALARS_BROWSER.ENGAGEMENT.ACTIVE_TICKS","[u'false']" "SCALARS_BROWSER.ENGAGEMENT.MAX_CONCURRENT_TAB_COUNT","[u'false']" "SCALARS_BROWSER.ENGAGEMENT.MAX_CONCURRENT_WINDOW_COUNT","[u'false']" "SCALARS_BROWSER.ENGAGEMENT.RESTORED_PINNED_TABS_COUNT","[u'false']" "SCALARS_BROWSER.ENGAGEMENT.TAB_OPEN_EVENT_COUNT","[u'false']" "SCALARS_BROWSER.ENGAGEMENT.TOTAL_URI_COUNT","[u'false']" "SCALARS_BROWSER.ENGAGEMENT.UNFILTERED_URI_COUNT","[u'false']" "SCALARS_BROWSER.ENGAGEMENT.UNIQUE_DOMAINS_COUNT","[u'false']" "SCALARS_BROWSER.ENGAGEMENT.WINDOW_OPEN_EVENT_COUNT","[u'false']" We should restrict these scalars to record only in the parent, i.e.: > record_in_processes: ["main"] This change is needed in Scalars.yaml: https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Scalars.yaml After the change, make sure that building still works properly using: > mach build Also run some tests to make sure nothing broke: > mach test browser/modules/test/browser/browser_UsageTelemetry*
Reporter | ||
Comment 1•6 years ago
|
||
While we're here, we can also restrict these two: "SCALARS_TELEMETRY.OS_SHUTTING_DOWN","[u'false']" "SCALARS_TIMESTAMPS.FIRST_PAINT","[u'false']"
Comment 2•6 years ago
|
||
Hey! I just started with mozilla development and would like to fix this.Just need a few resousrce to know how to fix it? Can anyone help me out here? Thanks
Comment 3•6 years ago
|
||
Hi Rohan! As outlined in comment 0, the "record_in_processes" property needs to be set to "main" only for the scalars listed in comment 0 and 1.
Assignee: nobody → rohan17089
Comment 4•6 years ago
|
||
Thanks for the quick reply! I did check all these scalars and it is already set to main only. Couldn't find the following scalar though "SCALARS_TELEMETRY.OS_SHUTTING_DOWN","[u'false']" perhaps telementry might right to another type of build and for the following scalar "SCALARS_TIMESTAMPS.FIRST_PAINT","[u'false']" the main written wasnt in single quotes,don't know if it makes a difference or not This is all what i could figure out,waiting for your further reply.
Comment 5•6 years ago
|
||
(In reply to Rohan Rajpal from comment #4) > Thanks for the quick reply! > > I did check all these scalars and it is already set to main only. Good point. I cross-checked and you're right, all these scalars are already set to "main". Rohan, I think you're done here :) I've needinfo'd you on another good bug if you're interested in taking more! @Frank, looks like the list of scalars from comment 0 comes from bug 1423446: we shouldn't be seeing these scalars in the content processes though. I quickly checked my builds and looks like we're sending the right stuff. Is this a mistake in the list or some unexpected behaviour in the pipeline code for scalars?
Assignee: rohan17089 → nobody
Flags: needinfo?(fbertsch)
Comment 6•6 years ago
|
||
Everything looks correct: - The list I gave is all probes that have *only* reported in the parent process - This bug is for restricting scalars to those - It looks like those scalars are already restricted, so we're good to go!
Flags: needinfo?(fbertsch)
Comment 7•6 years ago
|
||
Thanks Frank!
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•