It would be interesting to know whether this feature will be actively used once released. Of course the user base for restricted profiles will be really small in comparison to 'normal profiles'. And I assume this is a feature that will be mostly used in the final release version (and not nightly, auroa, beta) where telemetry is not enabled by default. So we should really set our expectations.
Bug 1183724 will tell us how often Firefox is launched in a guest session. As long as guest session == kidfox, this probe might give us what we need.
(In reply to :Margaret Leibovic from comment #1) > Bug 1183724 will tell us how often Firefox is launched in a guest session. > As long as guest session == kidfox, this probe might give us what we need. Guest mode and restricted profiles do share most of the code but they have a different set of restrictions and inGuestMode() will return false for restricted profiles. Right now we don't even have a public isRestrictedProfile() method. Even RestrictedProfiles.isUserRestricted() will return true for restricted profiles and guest mode, because both have some kind of restrictions.
I feel this is important before we ship, we want to know how much this is being used, is there also a way to get the time it's in that mode?
We can certainly try. This close to the deadline, it's not entirely a given.
Summary: Evaluation: Telemetry for KidFox → basic probe for KidFox usage
Barbara, do you have a concrete list of things you'd like to measure? Usage minutes in this mode might not be technically possible for v1(I'd know when to start the timer...but when to stop it is the tricky question) and I'd definitely need to go through FHR and its approval process for that.
a) Do people even use it As long as we can clearly identify how many sessions are in kidfox mode vs. parent/regular mode, that's the most important metric for now. b) How do people use it - If possible for later, we should get the timer stuff setup to figure out if the feature is even fully being used (or just tried and then forgotten about). - What kind of things are being restricted via the parents settings panel to find trends I'm still waiting for a full flow (from Sam) to understand where other metric check points (e.g. splash screen) are but that shouldn't block you for now. I hope that clarifies things.
Sounds like we should just add to the FENNEC_GECKO_STARTUP_ACTION enum
Assignee: ally → s.kaspari
Status: NEW → ASSIGNED
I added a new StartupAction called RESTRICTED. Does this work? Regarding the first run (bug 1191208): The "Start browsing" button will send "firstrun-browser" too. The "Learn more" link doesn't send anything. Is this okay?
Attachment #8644895 - Flags: review?(mark.finkle)
(In reply to Barbara Bermes [:bbermes] from comment #6) > - What kind of things are being restricted via the parents settings panel to > find trends What would be the best time to send this? At the beginning of a restricted session? Should we send every restriction with on/off or a list of enabled restrictions (Probably depends on how we want to evaluate these)? We might need to postpone this to 43 (Or try to uplift).
Comment on attachment 8644895 [details] [diff] [review] 1184190-kidfox-telemetry.patch That should work. I made sure the Histogram definition had some empty "bins" so we shouldn't need anything else.
Attachment #8644895 - Flags: review?(mark.finkle) → review+
(In reply to Sebastian Kaspari (:sebastian) from comment #8) > The "Learn more" link doesn't send anything. Is this > okay? Mostly up to Product. My only thoughts would be: Should a "learn more" probe be Histogram-Telemetry or UI-Telemetry? Given that "firstrun-browser" is UI-Telemetry, I'd lean to doing the same for the link, if needed at all.
url: https://hg.mozilla.org/integration/fx-team/rev/7f0cc9a2bf79950da4f9a4c4ab7df7c73e5a497d changeset: 7f0cc9a2bf79950da4f9a4c4ab7df7c73e5a497d user: Sebastian Kaspari <email@example.com> date: Sun Aug 09 19:58:43 2015 +0200 description: Bug 1184190 - Send RESTRICTED startup action when restricted profile is used. r=mfinkle
You need to log in before you can comment on or make changes to this bug.