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

Status: RESOLVED INCOMPLETE

(Mozilla Labs Graveyard :: Test Pilot Data Requests, defect)

Description

[Jono Xia]

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

[Hamilton]

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.

Comment 2

[Jono Xia]

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

[Hamilton]

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

[Hamilton]

*bump* is this still of interest to the requester?

Comment 5

[Dietrich Ayala (:dietrich)]

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

[Jinghua zhang]

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.)

Comment 7

[Dietrich Ayala (:dietrich)]

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

[(dormant account)]

I also don't have an immediate use for this data

Comment 9

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

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.

Comment 10

[Hamilton]

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

[Jinghua zhang]

+ jono

Comment 12

[Dietrich Ayala (:dietrich)]

(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

[Hamilton]

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.