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)
Firefox
General
Tracking
()
NEW
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.
Comment 1•14 years ago
|
||
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
Reporter | ||
Comment 2•14 years ago
|
||
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?
Comment 3•14 years ago
|
||
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).
Updated•14 years ago
|
Assignee: cbeard → mak77
Status: NEW → ASSIGNED
Reporter | ||
Comment 4•14 years ago
|
||
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.
Comment 5•14 years ago
|
||
> 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.
Comment 6•14 years ago
|
||
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!
Comment 7•14 years ago
|
||
Not sure if this needs to block final. Chris: how important are having these variables to your plans for snippets?
blocking2.0: --- → ?
Reporter | ||
Comment 8•14 years ago
|
||
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: ? → -
Updated•13 years ago
|
Whiteboard: [about-home]
Comment 10•13 years ago
|
||
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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•