New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 726338 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Indicate whether a UMA/UKM record was recorded in chrome custom tabs.

Project Member Reported by bmcquade@chromium.org, May 25 2017

Issue description

In UMA, we record a histogram CustomTabs.Visible to know whether Chrome was running in custom tabs mode. This allows us to infer whether a given UMA record should be attributed to CCT when doing analysis.

We'd like to record a similar signal in UKM.

Given that UMA and UKM both use SystemProfileProto, it seems like adding a field to that proto to indicate whether chrome was running in CCT mode would be the best path forward.

The main open question is whether Chrome can run in both CCT and non-CCT mode over the course of a UKM or UMA record being cut. If that's the case, we may want to consider more fine grained reporting on the UKM side, such as recording whether a given page load was loaded in CCT or non-CCT mode.
 
Cc: asvitk...@chromium.org
Owner: bcwh...@chromium.org
Status: Assigned (was: Untriaged)
Summary: Indicate whether a UMA/UKM record was recorded in chrome custom tabs. (was: indicate whether a UMA/UKM record was recorded in chrome custom tabs)
A bit of tracing shows that the "CustomTabs.Visible" value is set on every activity "resume" based on whether it is a ChromeActivity or a CustomTabActivity.

So this value can apparently run both over the lifetime of the process and inside any arbitrary UMA reporting interval.

Does that mean there needs to be a flag added to every UKM metric to indicate this?
Cc: bmcquade@chromium.org
So for UMA, we cut a new UMA log every when on backgrounded, so entering custom tab mode will be in a different UMA log than the one for regular Chrome. I believe UKM doesn't currently use the foreground/background lifecycle to cut logs - so I think this will need to be done too like UMA to have the field properly reflect the status.
Would you consider the flag "custom tab" to be part of the "source" or part of the "report"?  I'm thinking "source"...
RE: comment #3, I think we persist and flush UKM records when backgrounded on Android using same logic as UMA. So hopefully we should be covered here.
Only question I have - are we sure that the SetCustomTabVisible callback is synchronized relative to the onPause/onResume Android calls? If callback ordering ever gets inverted then it seems like we could log the wrong boolean value in each UMA/UKM record.
It's set with every onResume call so every activity change should set it correctly.  There's always the possibility that something could continue running in the background from a custom tab after a normal tab got loaded, or vice-versa, but that seems so unlikely that it would get lost in the noise.

Comment 9 by holte@chromium.org, Sep 1 2017

Components: Internals>Metrics>UKM
Brian was there any more work to be done on this? 

I queried the logs and I'm seeing some data having CCT marked as true. So I believe we can close this?
Status: Fixed (was: Assigned)
Yes.  This was submitted before the recent beta cut so will be part of M62.

Sign in to add a comment