1593133 - What's New Page should show up in the most recent active window

Status: NEW

(Firefox :: Messaging System, defect, P3)

Description

[Liz Henry (:lizzard) (relman/hg->git project)]

From bug 1592852 , dzielaski is asking that after an update, the What's New Page should be shown in the most recently active window and tab, rather than in the oldest / first tab.

Comment 1

[:Gijs (he/him)]

What's the priority here? This bug isn't tracked for any releases, and I think multi-window sessions are likely a tiny minority given how few people "even" use more than a few tabs... but I could be wrong. We might have data on this...

(I'm going to argue this is just a bug, so setting type to defect instead of enhancement.)

I'm not sure this is the best component as the code setting the overridePage is in BrowserGlue.jsm, but I'm not sure we have anything better...

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

I'll leave that prioritizing to the product team; I just wanted to capture the idea and see how easy or difficult it would be to implement.
And, secondarily, I'm looking into whether this behavior has changed between the 69 and 70 releases.

Tim, what do you think of the idea?

Comment 3

[Tim Spurway [:tspurway]]

Gijs has a good point about multi0-window sessions. I think it's a P3

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

From looking at data from chutten and tdsmith I'm not sure those assumptions are correct,

40% of subsessions reported having fewer than 2 tabs open, max: https://mzl.la/2PA7OKh

Looking at TAB_COUNT, which is approximately weighted by how long users spend actively using the browser, suggests that about 70% of activity happens in sessions with more than one tab https://mzl.la/334W5HA

Fewer than 3.5M clients have stayed under 2 tabs in Firefox release 70 so far.
All the rest have spent at least a little time with 2+ tabs. (https://sql.telemetry.mozilla.org/queries/65771/source#167038)

Comment 5

[Marissa (Reese) Wood]

Good afternoon! We are narrowing in on the Relationship KPI and would like to see if we can get this bugged move higher in priority. This is addressing the question how important is this to product - very much so.
We want reach the 17M folks who aren't currently getting the WNP updates. Please feel free to ping me if you need any info.

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Reese - We aren't sure that this has much of an impact and we don't have a good way to measure it.
It does seem possible that it would have some impact but it seems very unlikely to be 17M worth.

I'm not sure what you mean by 17M people not getting the WNP. Where is that number coming from exactly?

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

If this is what you mean, from my conversations with dzielaski, then I think you're talking about this query looking at the pattern of early updates in 70.0

https://sql.telemetry.mozilla.org/queries/65775/source#167049

That shows a large number of users updating to 70.0 and a long tail of users who likely already had an update to an earlier version downloaded and staged but not applied. So, to get to 70.0 they would need to restart again or leave Firefox open for another day to get to the latest update (which is now 70.0.1, by the way, which doesn't get a WNP at all.)

This bug, really a feature/enhancement request, doesn't seem to have anything to do with that group of users who during the first week of the release (or so) updated from an older version to a pre-70 version, for example, someone updating from 69.0 to 69.0.3.

Please reach out to me if you need more clarification, I'm happy to help

Comment 8

[Tim Spurway [:tspurway]]

:chutten, do we have any data that would help us understand how many folks are affected by their WNP showing up on an inactive (non-foreground, non-focused) window when they upgrade to a new version?

:mardak, do you have any idea the amount of effort required in fixing this bug?

Comment 9

[Chris H-C :chutten]

Inactive amongst all windows or inactive amongst restored Firefox windows? Because though I can answer neither of those properly, we can get a decent upper bound on the second one by looking at the value of FX_SESSION_RESTORE_NUMBER_OF_WINDOWS_RESTORED and counting how many clients even restore multiple windows in the first place.

Comment 10

[Tim Spurway [:tspurway]]

:chutten, I think inactive among restored Firefox windows would be the right way, though, tbh, either would probably give us a ballpark figure of how big the opportunity is. If there are a large percentage of users (say > 25%) that open Firefox with multiple restored windows, then we can start to make some cost vs. benefit to investing engineering time towards this.

Also, I followed up with :mardak, who's initial cost estimate in terms of engineering time/complexity was tricky/non-trival/medium complexity, so I would tend to stick with the P3 on this unless the potential benefit proves to be great.

Comment 11

[Ed Lee :Mardak]

Looking at FX_SESSION_RESTORE_NUMBER_OF_WINDOWS_RESTORED, looks like nearly 80-90% of session restores are for 1 window depending on the update channel. And 8-14% have 2 windows, which maybe we can guess on average the first window is the active window half of the time? So overall probably 90%+ of the time, we're opening the whats-new-page in the active window already.

Assuming this is correctly counting browser.startup.homepage values:
https://sql.telemetry.mozilla.org/queries/66231/source
"" empty == default 1 behavior seems to show 95% of people have the default behavior of showing the homepage and not restoring a session when launching firefox. But most likely people are getting the automatic session restore on update anyway. (?)

Code-wise, this does seem a bit tricky in that the way the whats-new-page is shown is treated like how firefox can be launched with a specific url. At startup, these urls to open are passed to the initial firefox window, which then decides if additional windows should be opened by session restore, and only after those are opened can we determine which window is the active one (most recently used -- not necessarily the last or first window opened).

So then session restore would need to know how to open the extra urls in the correct target window while also making sure the initially opened window doesn't open the extra urls that were passed in as window arguments.

Comment 12

[Chris H-C :chutten]

(In reply to Ed Lee :Mardak from comment #11)

Looking at FX_SESSION_RESTORE_NUMBER_OF_WINDOWS_RESTORED, looks like nearly 80-90% of session restores are for 1 window depending on the update channel. And 8-14% have 2 windows, which maybe we can guess on average the first window is the active window half of the time? So overall probably 90%+ of the time, we're opening the whats-new-page in the active window already.

That's what it looks like to me, also.

Assuming this is correctly counting browser.startup.homepage values:
https://sql.telemetry.mozilla.org/queries/66231/source
"" empty == default 1 behavior seems to show 95% of people have the default behavior of showing the homepage and not restoring a session when launching firefox. But most likely people are getting the automatic session restore on update anyway. (?)

telemetry.main is one row per ping. To get the number of clients (Firefox profiles) you should use COUNT(DISTINCT client_id) AS client_count in your SELECT... but I expect the proportion to be roughly the same.

(and, to be clear, profiles aren't people either (we did this in Telemetry on purpose), but the questions we're asking are probably in terms of profiles anyway, so I guess it doesn't matter except for pedantry)