Open Bug 593379 Opened 14 years ago Updated 2 years ago

Populate about:home localStorage with details to allow for custom content

Categories

(Firefox :: General, defect)

defect

Tracking

()

Tracking Status
blocking2.0 --- .x+

People

(Reporter: johnath, Unassigned)

Details

(Whiteboard: [about-home])

Engagement would like the about:home localStorage DB to have a set of information supplied to allow for tailoring dynamic content. This information would not be sent over the wire since it is mildly privacy-sensitive (e.g. "Is sync active?", "Has the user ever installed an addon," etc) but would allow a dynamic content blob to inspect localStorage and decide which content to present to the user.

Beard has said he'll supply a candidate list of such properties, so I'm provisionally assigning this to him, though I suspect mak will do the actual implementation work.
I'd like to see two metrics for us to be able to offer support:

total_crashes  - the total number of crash reports submitted
recent_crashes - number of crashes in past 120 hours
From email:

- user_is_new
"true" if within first 30 days of installing Firefox

- user_has_not_tried_sync_feature
"true" if sync has never been configured (regardless if enabled or not)

- user_has_not_installed_a_persona
"true" if personas have never been used (regardless if enabled or not)

- user_has_not_installed_an_extension
"true" if no extensions have been installed (excluding search plugins and nsapi plugins)

- total_crashes
total number of crashes experienced by user

- crashes_past_week
number of crashes in the past week

d2d_enabled
- is d2d enabled on this user's machine


IT seems to feel that HTTPS delivery of snippets is more containable than once thought (they were working off some bogus numbers in terms of how much traffic this would generate). If we do end up going with an HTTPS snippet, the following is also a very-nice-to-have, but a total non-starter for http snippet delivery.

installed_addons 
// array of installed extensions, background, plugins, etc. with name, version, type and state see bug 564092

Marco - can you take this one as well? Do you need more information from me or Chris?
I just have to figure out how to make this not expensive. guess we'll fetch info on idle and update them daily, so they won't be real-time but a bit cached (there is a possibility we could suggest trying acceleration to a user that has just activated it, for example).
Assignee: cbeard → mak77
Status: NEW → ASSIGNED
I think updating on idle is fine, yeah. These values don't change very often, and while we could hook up all the necessary listeners all over, I don't think that kind of granularity is required here.
> IT seems to feel that HTTPS delivery of snippets is more containable than once
> thought

This is true if the request volume is not unlike blocklist pings.
The request volume will be *maximally* like blocklist pings. We can make it less, if you'd like. See bug 563738 which is where we'll control how often we check for updates. Let your opinions be known!
Not sure if this needs to block final. Chris: how important are having these variables to your plans for snippets?
blocking2.0: --- → ?
Beard just walked by and agreed this is P2 at best, shouldn't be permitted to delay FF4 by more than an hour. -> blocking-
blocking2.0: ? → -
Actually putting this on the .x list for now.
blocking2.0: - → .x
Whiteboard: [about-home]
I seem to never be able to arrive at this bug (whose priority needs to be clarified), I'll be happy to mentor anyone willing to work on it, but I don't have the resources to do that directly atm.
Assignee: mak77 → nobody
Status: ASSIGNED → NEW
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.