ChromeOS should record FileBrowser.CreateNewFolder.... events

chrome/tools/extract_actions.py

Index: chrome/tools/extract_actions.py
diff --git a/chrome/tools/extract_actions.py b/chrome/tools/extract_actions.py
index 739e3ee6529ac9d6392f8b76d7bff118a0857bcf..342408fc2630e6a27b14b7327f6a30bc65edad95 100755
--- a/chrome/tools/extract_actions.py
+++ b/chrome/tools/extract_actions.py
@@ -223,6 +223,9 @@ def AddChromeOSActions(actions):
   # Actions sent by Chrome OS cryptohome.
   actions.add('Cryptohome.PKCS11InitFail')
 
+  # Actions sent by Chrome OS File Browser.
+  actions.add('FileBrowser.CreateNewFolder.hhaomjibdihmijegdhdafkllkbggdgoj')

[Ilya Sherman, 2011/11/11 23:39:20]

Can this be named "FileBrowser.CreateNewFolder" instead, without the extension
name appended?

[Ilya Sherman, 2011/11/11 23:39:20]

Hmm, I'm confused.  It looks like [1] calls metrics.recordAction() both for
"Create.*" and for "CreateNewFolder".  How does one of these generate a
histogram, and the other one generate a "user action" count?

[1]
http://codereview.chromium.org/8490014/diff/4001/chrome/browser/resources/fil...

[Vladislav Kaznacheev, 2011/11/14 10:47:12]

I should have mentioned one more CL (http://codereview.chromium.org/8491038). It
changes "Create.<type>" user action into "Create" histogram with type as a
value.

Sorry about the confusion. 

On 2011/11/11 23:39:20, Ilya Sherman wrote:

[Vladislav Kaznacheev, 2011/11/14 10:47:12]

My Javascript code uses chrome.experimental.metrics API. The current
implementation appends the extension name unconditionally in order to guarantee
unique names across a (potentially) large number of extensions that could use
the API in the future.

In reality my extension is the first client of this API with the second client
nowhere in sight. I have a permission from the API developers to change the
implementation within reason.

Personally I think extension names are ugly. I think that we can get rid of them
and check for possible name clashes when adding a new action to
chromeactions.txt

On 2011/11/11 23:39:20, Ilya Sherman wrote:

[Ilya Sherman, 2011/11/14 12:08:14]

Ah, that makes more sense now.  Thanks for the clarification.

On 2011/11/14 10:47:12, Vladislav Kaznacheev wrote:

[Ilya Sherman, 2011/11/14 12:08:14]

Is the chrome.experimental.metrics API intended to be used only be extensions
shipped as part of the Chromium source, or by external extensions as well?

If it is intended to be used only be extensions that are directly included as
part of Chromium, we should definitely not be appending the extensions names. 
Name clashes in such extensions' metrics do not seem any more likely than name
clashes everywhere else where we log metrics, so there's no need to do extra
work to avoid them for this particular case.

If the API is intended to be used by external extensions as well, it's probably
a good idea to have a chat with at least Jim Roskind (jar@) about the design of
this API and how third party extensions could make use of it (since metrics are
generally not released externally).

On 2011/11/14 10:47:12, Vladislav Kaznacheev wrote:

[petkov, 2011/11/14 14:03:09]

jar@ should definitely take a look. I'd think that we shouldn't expose metrics
to external extensions because the metrics data is not visible outside Google.
That would mean that we don't have to worry about name collisions.

On 2011/11/14 12:08:14, Ilya Sherman wrote:

+
 def GrepForActions(path, actions):
   """Grep a source file for calls to UserMetrics functions.