Closed Bug 971171 Opened 11 years ago Closed 11 years ago

Measure with telemetry how many times people see about:newtab

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 30
Tracking Status
firefox28 --- verified
firefox29 --- verified
firefox30 --- verified
b2g-v1.3 --- fixed

People

(Reporter: benjamin, Assigned: gfritzsche)

References

Details

(Keywords: privacy-review-needed)

Attachments

(1 file, 2 obsolete files)

We're going to be doing some experiments with the new-tab page, but we don't seem to have good data on how many people actually see the new-tab page. We should measure that!

* middle-clicking a link into a new tab should not trigger the counter, nor should opening a new window unless about:newtab is the user's home page instead of about:home
* opening a new tab with control-t or with the mouse should trigger the counter

Note: we already have NEWTAB_PAGE_PINNED_SITES_COUNT/NEWTAB_PAGE_ENABLED/NEWTAB_PAGE_BLOCKED_SITES_COUNT, but those don't actually measure usage. This measure is intended to be about usage.

This is a one-time measurement for now, so please set it to expire after a couple releases.

gfritzsche can you take this?
Taking a look today.
Depends on: 972341
Attached patch Add probe for when about:newtab is shown (obsolete) (deleted) — Splinter Review
ttaubert managed to really simplify the handling for about:newtab visibility in bug 972341, this patch depends on the patches there.
Status: NEW → ASSIGNED
I was hoping to uplift this to 29 or even 28, actually. How complex are the dependencies?
Alright, it's rather unlikely that we'll get this on 28 with the changes in bug 972341, so i'll do a seperate patch going for this.
Yes, gPage.init() is called for pages that are actually visible and for pages preloaded in the background. You need to insert your code here:

https://hg.mozilla.org/mozilla-central/annotate/a62bde1d6efe/browser/base/content/newtab/page.js#l87

So that it's executed only if this.allowBackgroundCaptures==true. This is then called for tabs opened through gBrowser.addTab(). As dicussed, you need a separate piece of code for the homepage case and you won't catch any loads caused by typing "about:newtab" into your url bar.
Flags: needinfo?(ttaubert)
Oh, i completely missed that it should go into the mutation observer :(
Thanks.
Attached patch Add probe for when about:newtab is shown, v2 (obsolete) (deleted) — Splinter Review
This looks good in my local testing. Tim, can you review this?

As mentioned, this doesn't cover directly navigating to about:newtab, which does not seem important.
It also doesn't cover about:newtab displays in a OOP Window, but i assume that's not important either at this time.
Attachment #8375574 - Attachment is obsolete: true
Attachment #8375669 - Flags: review?(ttaubert)
Attachment #8375669 - Flags: feedback?
Attachment #8375669 - Flags: feedback?
Comment on attachment 8375669 [details] [diff] [review]
Add probe for when about:newtab is shown, v2

Review of attachment 8375669 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good to me. I can't say much about the Telemetry histogram and I assume you made sure by talking to people that this will be able to display data as needed :) I also don't have an opinion about the expiration version number and assume you have confirmed that as well.

Another thought: the mutation observer is only called when the newtab page is enabled, i.e. the tiles are shown. The change in browser.js however adds a value to the histogram even if browser.newtabpage.enabled=false. As there is no good way of checking that here I think you should just check the pref as well.

This all would be so much easier with the dependency fixed :)

::: toolkit/components/telemetry/Histograms.json
@@ +4016,5 @@
>    },
> +  "NEWTAB_PAGE_SHOWN": {
> +    "expires_in_version": "35",
> +    "kind": "boolean",
> +    "description": "Count of when about:newtab was shown."

Maybe "Number of times about:newtab was shown." ?
Attachment #8375669 - Flags: review?(ttaubert) → feedback+
Ah, good point on the pref. How about this?
Attachment #8375669 - Attachment is obsolete: true
Attachment #8376178 - Flags: review?(ttaubert)
Comment on attachment 8376178 [details] [diff] [review]
Add probe for when about:newtab is shown, v3

bsmedberg, can you sign off on the telemetry parts?
Attachment #8376178 - Flags: review?(benjamin)
Comment on attachment 8376178 [details] [diff] [review]
Add probe for when about:newtab is shown, v3

I'm a little surprised by "or window" in the histogram description because when I open a new window I get about:home not about:newtab. Is that something which happens by default or is it something that only happens if you change your homepage from about:home to about:newtab?
Attachment #8376178 - Flags: review?(benjamin) → review+
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #12)
> Is that
> something which happens by default or is it something that only happens if
> you change your homepage from about:home to about:newtab?

I only meant to describe the case where you change the homepage to about:newtab.
No longer depends on: 972341
Blocks: 973532
OS: Linux → All
Hardware: x86_64 → All
Version: unspecified → Trunk
(In reply to Georg Fritzsche [:gfritzsche] from comment #13)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #12)
> > Is that
> > something which happens by default or is it something that only happens if
> > you change your homepage from about:home to about:newtab?
> 
> I only meant to describe the case where you change the homepage to
> about:newtab.

This does also come in handy should we decide/get around to fix bug 725579.
Comment on attachment 8376178 [details] [diff] [review]
Add probe for when about:newtab is shown, v3

Review of attachment 8376178 [details] [diff] [review]:
-----------------------------------------------------------------

Did some quick checks whether we add a value to the histogram in all cases and the patch works as expected, thanks!
Attachment #8376178 - Flags: review?(ttaubert) → review+
https://hg.mozilla.org/mozilla-central/rev/b431599b4e68
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 30
Comment on attachment 8376178 [details] [diff] [review]
Add probe for when about:newtab is shown, v3

Requesting uplift approval per comment 3.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): n/a
User impact if declined: No metrics on actual about:newtab impressions.
Testing completed (on m-c, etc.): Checked expected use-cases, now baking on m-c.
Risk to taking this patch (and alternatives if risky): Low-risk, it just adds a new telemetry probe without changing existing behaviour.
String or IDL/UUID changes made by this patch: None.
Attachment #8376178 - Flags: approval-mozilla-beta?
Attachment #8376178 - Flags: approval-mozilla-aurora?
Attachment #8376178 - Flags: approval-mozilla-beta?
Attachment #8376178 - Flags: approval-mozilla-beta+
Attachment #8376178 - Flags: approval-mozilla-aurora?
Attachment #8376178 - Flags: approval-mozilla-aurora+
I would like to see this verified on Beta and Aurora once the builds are out so we can trust the data.
We can check the counts in about:telemetry, "Histograms" - filter with e.g. "newtab".
Keywords: verifyme
From last Nightly with new profile, one new tab opened:

NEWTAB_PAGE_SHOWN
1 samples, average = 1, sum = 1

0 |  0  0%
1 |#########################  1  100%
Status: RESOLVED → VERIFIED
Keywords: verifyme
Whiteboard: [good first verify]
For the Beta & Aurora verification it would be nice to confirm that we don't count opening a new tab with the newtab page disabled (either by directly setting browser.newtabpage.enabled=false or using the top-right icon on the newtab page).
(In reply to Georg Fritzsche [:gfritzsche] from comment #23)
> For the Beta & Aurora verification it would be nice to confirm that we don't
> count opening a new tab with the newtab page disabled (either by directly
> setting browser.newtabpage.enabled=false or using the top-right icon on the
> newtab page).

This bug is not deemed a high priority to verify before we release Firefox 28. Is there some reason we should re-evaluate that position?
I mainly added the details for people checking here due to "good first verify".
This is not critical but might be good to check this works the same in Beta & Aurora before basing decisions on the data.
(In reply to Georg Fritzsche [:gfritzsche] from comment #25)
> This is not critical but might be good to check this works the same in Beta
> & Aurora before basing decisions on the data.

Fair enough, flagging this for verification along those lines.
Keywords: verifyme
Whiteboard: [good first verify]
Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0
Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0

On Firefox 28 beta 6 (Build ID: 20140224220227) and latest Aurora from 2014-02-26, about:telemetry/Histograms works as expected, the counter is triggered when I open a New tab (File->New tab; ctrl/cmd+T or click on + button) or when the homepage is set to about:newtab in Options/General. With browser.newtabpage.enabled pref set to false, no results are displayed for NEWTAB_PAGE_SHOWN. Althought, if I:

1. Open a new tab page; NEWTAB_PAGE_SHOWN=1
2. Click on Hide the new tab page button (in the upper right corner); NEWTAB_PAGE_SHOWN=1
3. Close the new tab from step 2, open another new tab page and NEWTAB_PAGE_SHOWN=2 

For the next new tab pages opened, the counter is not triggered. Is this expected? Because when I click on Show the new tab page, the counter is triggered right away.
Flags: needinfo?(georg.fritzsche)
(In reply to Alexandra Lucinet, QA Mentor [:adalucinet] from comment #27)
> For the next new tab pages opened, the counter is not triggered. Is this
> expected? Because when I click on Show the new tab page, the counter is
> triggered right away.

No, it's not expected but at least on Nightly it only triggers for the first new tab page that you open after that (does that match what you see on Beta and Aurora?).
On the other hand we don't count the impression when you click the "show the new tab page button" (only for new tabs afterwards).

If it matches the Nightly behaviour i don't think it matters enough to fix Beta/Aurora.
Flags: needinfo?(georg.fritzsche)
(In reply to Georg Fritzsche [:gfritzsche] from comment #28)

> No, it's not expected but at least on Nightly it only triggers for the first
> new tab page that you open after that (does that match what you see on Beta
> and Aurora?).

Yes, it's exactly the same. 
Although, since for "Show the new tab page" button the counter is triggered with the next New tab page opened, shouldn't it be the same for "Hide the new tab page" button? The behavior should be consistent. 
Is there any bug logged on this matter or should I file one?
(In reply to Alexandra Lucinet, QA Mentor [:adalucinet] from comment #29)
> Although, since for "Show the new tab page" button the counter is triggered
> with the next New tab page opened, shouldn't it be the same for "Hide the
> new tab page" button? The behavior should be consistent. 

This is overcounting by 1 for hiding (next new tab) and undercounting by 1 for showing (the new tab you just clicked on).
ttaubert and i didn't think it mattered enough to spend more time on this.
Blocks: 972936
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: