FHR Startup Graph Vertical Scale wrong time increments

RESOLVED WORKSFORME

Status

Firefox Health Report
Client: Desktop
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: Jim Jeffery not reading bug-mail 1/2/11, Unassigned)

Tracking

({regression})

Trunk
x86_64
Windows 7
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

Starting with the Nightly build on 4/9/13
cset:  https://hg.mozilla.org/mozilla-central/rev/b1fb34b07c17
Win7 x64 

The Graph showing the Start-up Profile time is wrong.  The 'x' (vertical scale)
is in the wrong time increments.

Likely due to bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=793735
Created attachment 735238 [details]
screenshot of FHR startup graph

Screenshot of Startup Graph
Note vertical scale:

Comment 2

5 years ago
Not sure if this is related or not, but before the update to today's Nightly, my health report showed my browser had been open for 731 min this month.  Immediately after restarting to update, that number became 6,743 min.
Just installed the latest Nightly that includes the layers refactor and the backout of 
bug 793735 and the FHR graph still looks incorrect, time on the 'x' axis is still in huge seconds increments. 

Is this something that will smooth out after some data collection or is something in the end-user profile now corrupt ?

Seeks thoughts before jumping into a new profile, but will do some testing later with a new profile on a limited basis for the time being.
Quick test with a profile I started a few days ago to test FHR is showing correctly on the 'x' axis, 1.5 2.0 2.5 3.0 3.5 4.0 (seconds)

must be somthing in my 'working profile' that maybe needs a reset ?
Looking in about:config I have these entries showing in 'bold' (user set) 
NOTE: I didn't set any of these, the software must have

app.update.lastUpdateTime.datareporting-healthreport-lastDailyCollection;1365084396
datareporting.healthreport.lastDataSubmissionFailureTime;1361824808909
datareporting.healthreport.lastDataSubmissionRequestedTime;1365603073270
datareporting.healthreport.lastDataSubmissionSuccessfulTime;1365603075004
datareporting.healthreport.lastPingTime;1365603075004
datareporting.healthreport.lastSubmitID;df9f5217-0ff5-40a5-95eb-a07488af7e74
datareporting.healthreport.nextDataSubmissionTime;1365689475004
datareporting.healthreport.service.firstRun;true


I am going to try 'resetting' those and see if anything changes.

Comment 6

5 years ago
There are no plans to prune bad data from clients affected by bug 793735.

Clearing those preferences will have no effect. Furthermore, you are advised against modifying those preferences as it may put FHR in an undefined state.
(In reply to Gregory Szorc [:gps] from comment #6)
> There are no plans to prune bad data from clients affected by bug 793735.
> 
> Clearing those preferences will have no effect. Furthermore, you are advised
> against modifying those preferences as it may put FHR in an undefined state.

Ok thanks, so ...  this will iron itself out in a few days/hours ?  Is the graph data on the FHR server and will be 'updated' to local end-user in hours/days ?
Created attachment 740908 [details]
Verticle time-line coming down

Seems that after some time that the times are now decreasing in the vertical axis and coming back into more reasonable times.
Vertical times on graph continue to show reasonable time steps even after the re-landing 
of but 793735 

Closing this now as WFM.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.