859863 - FHR Startup Graph Vertical Scale wrong time increments

Status: RESOLVED WORKSFORME

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

Description

[Jim Jeffery not reading bug-mail 1/2/11]

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

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

Attachment: screenshot of FHR startup graph

Screenshot of Startup Graph
Note vertical scale:

Comment 2

[Sean Smith]

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.

Comment 3

[Jim Jeffery not reading bug-mail 1/2/11]

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.

Comment 4

[Jim Jeffery not reading bug-mail 1/2/11]

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 ?

Comment 5

[Jim Jeffery not reading bug-mail 1/2/11]

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

[Gregory Szorc [:gps]]

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.

Comment 7

[Jim Jeffery not reading bug-mail 1/2/11]

(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 ?

Comment 8

[Jim Jeffery not reading bug-mail 1/2/11]

Attachment: 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.

Comment 9

[Jim Jeffery not reading bug-mail 1/2/11]

Vertical times on graph continue to show reasonable time steps even after the re-landing 
of but 793735 

Closing this now as WFM.