Can you create different buckets per non-internet protocol (file, chrome-extension) instead of completely exclude them? Extensions should be noted when changes happen that affect them, but they should not affect the intent decision (other than maybe, "wait one more milestone", in my opinion), because you can reach out to the developers using the web store contact details.
If they do not answer, the extension is inactive and it is the fault of the author (what if breaking changes are made to the extension system, such as manifest_version: 3? The extension will completely stop working anyway).

I hope the new tab page will not be tricky, though. Remember, its URL is a real URL (for Google and Bing, for example, if I remember correctly).

file:// URLs are more problematic because they usually never change... Which is why a different bucket would still be useful.

Actually, a bucket for internal pages could be useful to the author of the intent.


Anyway, if multiple buckets for the same feature (feature = zoom: document usage in buckets = web content, internal pages, file://, chrome-extension://) are not possible or whatever, then I guess only file:// matters (since most of the rest can be searched).

phistuck: sorry I missed your above suggestion.  We've found that it's really easy to fall into a trap of adding more and more metrics for things that might be interesting (especially when we're talking about adding a new dimension that multiplies the metrics - remember we already have two other dimensions here: CSS vs. JS and Regular vs. SVGDocument context), so we try to be pretty intentional about understanding exactly how we'll use the data before expanding it.

For chrome-extension I'm skeptical that we'd actually use UMA data for that.  We can't get the extension ID so all we'd know is that some extension is using it.  AFAIK we don't currently have a way to search the JS of all extensions in the store.  But we always do a deprecation period anyway (and are working on ways to make those warnings more visible to authors, including for extensions).  So I think we shouldn't worry about adding this unless/until we see problems arise and decide we should start explicitly searching/notifying extension authors specifically.

And for file:// I _think_ we want to treat that exactly the same as http:// - usage of content we don't control is usage regardless of the protocol.

So I suggest we keep this bug scoped to excluding the internal/extension URLs (since we've seen lots of examples for where that matters) and wait to see if we have concrete scenarios where we wish we had more of the data you're discussing.  Feel free to file a separate bug(s) now though if you want somewhere to track the potential interest.

#5 - as far as I know, the web store does have some way to search for in the code of all of the extensions.
Even more - in case there is no way to search, that makes it more important to include extensions in the usage metrics, because it "is usage regardless of the protocol". ;)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/146accf2581a4ac5184cc9c5f0f2e2a91bf4be23

commit 146accf2581a4ac5184cc9c5f0f2e2a91bf4be23
Author: rbyers <rbyers@chromium.org>
Date: Sat Dec 24 00:22:05 2016

Mute use counters for internal pages

Whenever a new top-level page is loaded, the UseCounter state is reset.  This CL extends that infrastructure to pass along the URL of the page that's being loaded.  We then use the scheme of the URL to decide if tracking usage metrics is useful or not, to avoid polluting our metrics with results from webui, DevTools, etc.

This CL makes no changes to the "legacy" counter histograms in order to preserve their semantics while we transition to the new histograms.

BUG= 652336 

Review-Url: https://codereview.chromium.org/2604633002
Cr-Commit-Position: refs/heads/master@{#440660}

[modify] https://crrev.com/146accf2581a4ac5184cc9c5f0f2e2a91bf4be23/third_party/WebKit/Source/core/frame/UseCounter.cpp
[modify] https://crrev.com/146accf2581a4ac5184cc9c5f0f2e2a91bf4be23/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/146accf2581a4ac5184cc9c5f0f2e2a91bf4be23/third_party/WebKit/Source/core/frame/UseCounterTest.cpp
[modify] https://crrev.com/146accf2581a4ac5184cc9c5f0f2e2a91bf4be23/third_party/WebKit/Source/core/page/Page.cpp
[modify] https://crrev.com/146accf2581a4ac5184cc9c5f0f2e2a91bf4be23/third_party/WebKit/Source/platform/weborigin/SchemeRegistry.cpp
[modify] https://crrev.com/146accf2581a4ac5184cc9c5f0f2e2a91bf4be23/third_party/WebKit/Source/platform/weborigin/SchemeRegistry.h

 Issue 293000  has been merged into this issue.