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

Issue 890502 link

Starred by 2 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Task



Sign in to add a comment

Track breakdown of how tabs were created at tab switcher open time.

Project Member Reported by zea@chromium.org, Sep 28

Issue description

I'd like to understand, at the time a user opens the tab switcher (or potentially at startup time), the breakdown of how tabs in the switcher were created. Example breakdown:
- manually created
- created via target=new
- created via intent from other app
- created via homescreen link
- created via custom tab -> open in chrome
 
+1! I would vote for at tab switcher open > startup (esp. if we're talking cold startup, which biases towards low end devices.)

Nicolas, what's "created via homescreen link"? The long-tap shortcut?

--- 

It would also be useful to understand how many get created (as opposed to how many stay open), because the distributions may be different & it would improve user action sequences.

My understanding of relevant UAs today:

1. MobileNewTabOpened is logged at least:
- When you open a tab from the menu
- When you open a tab in the stack view (i.e. the tab switcher)
- When you long tap open in background
- It does not include (tested w/ chrome://user-actions) tabs opened automatically by webpages (target=_blank or window.open)
- It probably does not include (unfortunately not testable with chrome://user-actions) tabs opened automatically (when you close all tabs and return to Chrome)


2. MobileNTPOpenedInNewTab is logged whenever an NTP is created. The comment says this includes the case where Chrome is opened with 0 tabs.

3. CustomTabsOpenedInChrome is already logged for open in Chrome from Custom Tabs

4. MobileReceivedExternalIntent.App is already logged for external intent opens

The delta I would propose is:

- Adding a new action (MobileNewTabOpened.AutomaticByWebPage?) for webpage-driven automatic tab opens (such as target=_blank and window.open)

- Adding a new action (MobileNewTabOpened.AutomaticOnStartup?) for the case when Chrome starts up and creates a new tab automatically because there are 0 tabs. If MobileNewTabOpened is already logged for this case, it would be nice to stop logging it so that plain MobileNewTabOpened == user opened a tab manually.

Yeah, definitely agree it would be great to understand how often the various categories get created.

And the "Created via homescreen" refers to when users to "add to homescreen" and then tap on that icon from the homescreen. No long tap necessary.

Sam, is the delta you're proposing in addition to what I propose? If so I agree. I was thinking the at tab switcher open data would be a histogram
Yes, I was thinking in addition to a histogram for currently-open tabs.

The behavior from the home screen is a little tricky. I just tested it, and it will or will not create a tab depending on whether one is already open with that site. It logs MobileReceivedExternalIntent.App though -- from a UA perspective I think we don't need to break it out further. Presumably it's rarely the source of new tabs.
It will create new tabs once you navigate away from the original page. So if you e.g. have reddit saved, and click a link, next time you tab the reddit icon it'll create a new tab.

But, granted this is going to be limited to users who add to homescreen, which likely isn't super common.
Labels: -Type-Bug Type-Task
Status: Assigned (was: Unconfirmed)
Status: Started (was: Assigned)
The following three metrics are recorded in the same bucket FromExternalApp, currently,
- created via intent from other app
- created via homescreen link
- created via custom tab -> open in chrome

Because after tab is created in Chrome, we don't know where is tab coming from anymore. We only knew the external app id at tab creation time, but not after that.
Maybe just log them as "unknown," and over time we should see that shrink? (Assuming we add tracking to log this.)
Sam, what do you mean "unknown"?

Currently, we don't have a way to distinguish these three different source further, we only know the tab was created from an external app. Therefore I was thinking record them in the same bucket.

Ah sorry, I misunderstood. Bundling all of those into one bucket SGTM.

What I was saying with the "unknown" bucket, is that presumably we don't know how the tabs which exist today were created. So when this first goes out, if we log a histogram when the tab switcher is opened the answer for all of those tabs will be - we don't know. Could also just exclude those tabs from being logged in the histogram, but it could be useful to get a sense of when the rest of the numbers are actually representative.
Project Member

Comment 10 by bugdroid1@chromium.org, Nov 12

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

commit e81d984e50d13b71167bdac970d0980f1a9cc674
Author: Mei Liang <meiliang@chromium.org>
Date: Mon Nov 12 22:01:16 2018

Add histograms about remain opened tabs' initial creation reason

This CL adds logging for the following histograms at tab switcher open
time:
  - Tabs.Tasks.TabCreated.Count.FromManuallyCreated
  - Tabs.Tasks.TabCreated.Count.FromTargetBlank
  - Tabs.Tasks.TabCreated.Count.FromExternalApp
  - Tabs.Tasks.TabCreated.Count.FromOthers

  - Tabs.Tasks.TabCreated.Percent.FromManuallyCreated
  - Tabs.Tasks.TabCreated.Percent.FromTargetBlank
  - Tabs.Tasks.TabCreated.Percent.FromExternalApp
  - Tabs.Tasks.TabCreated.Percent.FromOthers

Bug: 890502
Change-Id: I2fa8d8e20596c43057f172a65683ba1b1860a63c
Reviewed-on: https://chromium-review.googlesource.com/c/1313550
Commit-Queue: Mei Liang <meiliang@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Nicolas Zea <zea@chromium.org>
Reviewed-by: Yusuf Ozuysal <yusufo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607345}
[modify] https://crrev.com/e81d984e50d13b71167bdac970d0980f1a9cc674/chrome/android/java/src/org/chromium/chrome/browser/ChromeTabbedActivity.java
[modify] https://crrev.com/e81d984e50d13b71167bdac970d0980f1a9cc674/chrome/android/java/src/org/chromium/chrome/browser/TabState.java
[modify] https://crrev.com/e81d984e50d13b71167bdac970d0980f1a9cc674/chrome/android/java/src/org/chromium/chrome/browser/tab/Tab.java
[modify] https://crrev.com/e81d984e50d13b71167bdac970d0980f1a9cc674/chrome/android/java/src/org/chromium/chrome/browser/tasks/TasksUma.java
[modify] https://crrev.com/e81d984e50d13b71167bdac970d0980f1a9cc674/chrome/android/junit/src/org/chromium/chrome/browser/tabstate/TabStateUnitTest.java
[modify] https://crrev.com/e81d984e50d13b71167bdac970d0980f1a9cc674/tools/metrics/histograms/histograms.xml

Project Member

Comment 11 by bugdroid1@chromium.org, Nov 14

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

commit e45f8be19fdb67b95053e3667ef83837d52e5a36
Author: Mei Liang <meiliang@chromium.org>
Date: Wed Nov 14 02:17:32 2018

Follow up on histograms added in CL:1313550

This CL updates the histogram metadata.

Bug: 890502
Change-Id: I20fa1f69a3b7fc720fc314d2be98bff6fd175415
Reviewed-on: https://chromium-review.googlesource.com/c/1333781
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Commit-Queue: Ilya Sherman <isherman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607866}
[modify] https://crrev.com/e45f8be19fdb67b95053e3667ef83837d52e5a36/tools/metrics/histograms/histograms.xml

Sign in to add a comment