Analysis: What % of users restore the session by default?

ASSIGNED
Assigned to

Status

--
minor
ASSIGNED
8 years ago
2 years ago

People

(Reporter: jono, Assigned: dtang)

Tracking

Details

(Whiteboard: Analysis)

(Reporter)

Description

8 years ago
Requested by: Dietrich Ayala

Data should be in: Week in the Life v2

https://intranet.mozilla.org/Labs/TestPilot/Studies_And_Analysis#A_Week_In_the_Life_of_a_Browser_.28v2.29

Comment 1

8 years ago
For clarification, are we only looking to see if browser.sessionstore.resume_from_crash is different than the default?

If so, then the percentage of users who have the default set to true is 98.6%.

The other prefs we have here are:

browser.startup.page
browser.sessionstore.resume_session_once
browser.sessionstore.max_resumed_crashes

I can give you a breakdown of the other ones if you'd like.  Do let me know.
(Reporter)

Comment 2

8 years ago
We should also take a look at the number of windows/tabs restored on the session restore to see if it's 0, 1, or more than one -- somebody who has the pref turned on but is restoring 0 tabs on most startups isn't really "restoring a session" in the way we care about.

Comment 3

8 years ago
Are we looking to see what percentage of users de facto don't restore tabs but also have the default tab restore pref, or the percentage of users who have changed their prefs from the default?  The answer to the latter is a subset of the answer of the other.

I'll do a little more data munging and figure it out.

Comment 4

8 years ago
*bump* is this still of interest to the requester?
Yeah, I think so.

My question was mostly related to startup performance, so is a little broader than just session restore:

* home page of multiple URLs, and session restore set to *not* restore by default

* restore session by default (browser.start.page = 3)

* browser restored once (browser.sessionstore.resume_session_once). from updates of some kind, etc. can also get stuck like this if updates aren't applying, iirc. permissions errors and such.

Comment 6

7 years ago
Hamilton: Do we have the data from previous studies? 

Dietrich: If we don't have data for your questions now, are you interested to schedule a study to fetch user data on these? (It may take about 2-4 weeks from study implementation to data analysis.)
Whiteboard: Analysis
Cc'ing Taras (perf group leader) and Paul (session restore owner) to see if they can use this data, and if they have additional questions, etc.

I think we definitely could use this information, but I'm not working on anything that will immediately utilize it.

Taras and Paul, would this study help anything you're working on, or is there other information you need in this area?

Comment 8

7 years ago
I also don't have an immediate use for this data
I'm not working on anything that needs this info right now, but it would be nice to have and could result in re-prioritization of work.

Updated

7 years ago
Assignee: hulmer → dtang

Comment 10

7 years ago
Dietrich:

So it seems that to get these answers we would need to build these into the Week In The Life study.  I'll wait for Jono to respond to this bug to make sure what I'm saying is true. 

I have a few comments:

* home page of multiple URLs, and session restore set to *not* restore by default
- could you clarify what this means?  What might we look at to make this operational?

* restore session by default (browser.start.page = 3)
- we don't currently track this, but could roll it into the next one.

* browser restored once (browser.sessionstore.resume_session_once). from updates of some kind, etc. can also get stuck like this if updates aren't applying, iirc. permissions errors and such.
- we also don't track this ATM, but could.

Jono: I've been out of the TP loop for a while - am I right in assuming these are not tracked?

Comment 11

7 years ago
+ jono
(In reply to comment #10)
> * home page of multiple URLs, and session restore set to *not* restore by
> default
> - could you clarify what this means?  What might we look at to make this
> operational?

checking whether browser.startup.homepage have multiple URLs as a value, and whether browser.startup.page has a value of 3.

as the previous comments said, this data is not a priority right now, so no hurry.

Comment 13

7 years ago
Ok - in the meantime I'm setting this to minor importance in favor of other requests.  Feel free to comment on this bug if the priority changes.
Severity: normal → minor
Product: Mozilla Labs → Mozilla Labs Graveyard
You need to log in before you can comment on or make changes to this bug.