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

Issue 854363 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Metrics service embedder interface design mismatch with headless use-case

Reported by br...@amazon.com, Jun 19 2018

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce the problem:
_Chromium_ provides two interface classes for embedders looking to report metric
data back to an external server:

1. components/metrics/metrics_service_client.h
2. components/metrics_services_manager/metrics_services_manager_client.h

_Chrome_ provides one implementation of these interfaces for the Chrome
browser.  We have a headless use-case where we would like to collect metric
data, and have been exploring doing so through an implementation of the embedder
interfaces, similar to the Chrome implementation.

The embedder interface, as it currently stands, makes a number of assumptions
that the embedder is a user-controlled web browser.  This became clear as we
looked to implement the interface for a headless use-case.  Here are some
examples:

1. The |MetricsStateManager| class constructor takes a |PrefService| argument.
   The |PrefService| is subsequently passed on to a |CleanExitBeacon|, which
   attempts to read prefs::kStabilityExitedCleanly and
   prefs::kStabilityBrowserLastLiveTimestamp, and fails if these values have not
   been initialized.  For many headless use-cases, instances are "throw-away",
   and the notion of stateful preferences like these that live across browsing
   sessions is not applicable.  As a data point, when recently implementing the
   embedder interface for a headless use-case, I had to set ~50 preferences to
   some arbitrary values simply to avoid CHECK failures here:
   https://cs.chromium.org/chromium/src/components/prefs/pref_service.cc?l=121&rcl=8bc57470c7a7704da9dee46efc0da06748d1d3e4.
2. The |MetricsServicesManagerClient| class interface requires embedders to
   implement methods such as |IsMetricsConsentGiven()|, which is a user-based
   action.  Again for many headless use-cases, particularly around automation,
   there is no user.
3. The |MetricsServicesManagerClient| class interface requires embedders to
   implement |CreateEntropyProvider()|, which is ultimately used to setup field
   trials.  Field trials again will not apply to many headless use-cases.

Looking at the git log, it seems that the metrics embedder interface predates
the work on headless, which would explain many of the assumptions.  Is there any
plan to revisit the embedder interface to better support headless use-cases?

What is the expected behavior?

What went wrong?
.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 65.0.3325.181  Channel: n/a
OS Version: 
Flash Version:
 
Components: Internals>Headless Internals>Metrics
Status: Untriaged (was: Unconfirmed)

Sign in to add a comment