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
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.
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.
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.
*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.
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.)
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?
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.
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?
(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.
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.