Closed Bug 860238 Opened 7 years ago Closed 5 years ago

Breakdown: Handle "Profile Reset" gracefully in FHR

Categories

(Firefox Health Report Graveyard :: Client: Desktop, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mreid, Assigned: adw)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fxgrowth])

I'm not sure what the current situation is with regard to the Profile Reset feature in Firefox, but we should ensure that at minimum we flag that a reset has occurred.
OS: Linux → All
Hardware: x86_64 → All
The ideal in my opinion:

* Profile Reset should append to times.json recording that a reset has occurred.
* Profile Reset also needs to preserve FHR preferences and state files.
* FHR (on desktop and mobile) should include profile reset events alongside profile creation time in the submitted report.
* Presumably PR involves closing and reopening firefox(.exe), so on desktop there's no need to notify any listeners; the next time FHR runs it'll spot changed add-ons at so forth.
* On Android, FHR is a separate chunk of Java, so further consideration is needed if and when Profile Reset makes it to Fennec.
Blocks: fxdesktopbacklog
No longer blocks: fxdesktoptriage
Whiteboard: p=0
No longer blocks: fxdesktopbacklog
Summary: Handle "Profile Reset" gracefully in FHR → Breakdown: Handle "Profile Reset" gracefully in FHR
Whiteboard: p=0 → p=3 [qa?]
Flags: needinfo?(sguha)
Blocks: 1062345
Assignee: nobody → adw
Status: NEW → ASSIGNED
Iteration: --- → 35.1
Points: --- → 3
Whiteboard: p=3 [qa?]
Depends on: 1063704
Flags: qe-verify-
Depends on: 1063714
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fxgrowth]
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.