Closed Bug 829953 Opened 7 years ago Closed 7 years ago

about:healthreport resets everytime you close that tab

Categories

(Firefox Health Report Graveyard :: Web: Health Report, defect)

defect
Not set

Tracking

(firefox18 unaffected, firefox19 unaffected, firefox20+ fixed, firefox21+ verified)

VERIFIED FIXED
Firefox 21
Tracking Status
firefox18 --- unaffected
firefox19 --- unaffected
firefox20 + fixed
firefox21 + verified

People

(Reporter: mayankleoboy1, Assigned: gps)

References

()

Details

(Whiteboard: [fhr])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130112 Firefox/21.0
Build ID: 20130112030947

Steps to reproduce:

1. type about:healthreport in the URL bar. The page opens
2. Click "Help make nightly better" or click on the big green bar.
3. Healthreporting is turned on.
4. Type about:healthreport in the URL bar and press enter


Actual results:

the page again shows healthreport is off and asks if you want to make nightly better


Expected results:

What is turned on should remain on.
Summary: about:healthreport resets everytime → about:healthreport resets everytime you close that tab
In Addition datareporting.healthreport.service.enabled;true + the Checkmark in the UI (Options/Advanced/Data Choices) is set properly.
Component: Untriaged → Metrics and Firefox Health Report
Product: Firefox → Mozilla Services
Version: 21 Branch → unspecified
I have a few questions about the healthreports.

I use two Win7 machines with *vastly* different hardware.Both have the same profile. Whenever i use the other machine, i copy the complete profile folder of the first machine and paste it to the second.

How would this change the behaviour of the healthreports ? Will the two machines generate different healthreport histories on the moz servers , or will they be mixed together?
Blocks: 829887
I assume this 'only works with - ' Nightly builds and Aurora ?

I use hourly builds mostly from m-c and so far I see nothing but a blank page.

We're still gathering Data - stay tuned!
(In reply to mayankleoboy1 from comment #2)
> I have a few questions about the healthreports.
> 
> I use two Win7 machines with *vastly* different hardware.Both have the same
> profile. Whenever i use the other machine, i copy the complete profile
> folder of the first machine and paste it to the second.
> 
> How would this change the behaviour of the healthreports ? Will the two
> machines generate different healthreport histories on the moz servers , or
> will they be mixed together?

In the prototype design, if a profile was copied to a different machine, the first installation to submit would keep the history, and any subsequent submissions from other installations would detect that the previous document had already been deleted and would attempt to divorce the machine specific history.  :mreid should check this statement to let me know if I got it wrong. :)

:gps should describe how it works with the current implementation, and we should figure out if there are any improvements that should be made to future versions.  This isn't likely to be a very common event, but it will happen and if we can mitigate it, it is worth considering.
(In reply to Daniel Einspanjer :dre [:deinspanjer] from comment #4)
> (In reply to mayankleoboy1 from comment #2)
> In the prototype design, if a profile was copied to a different machine, the
> first installation to submit would keep the history, and any subsequent
> submissions from other installations would detect that the previous document
> had already been deleted and would attempt to divorce the machine specific
> history.  :mreid should check this statement to let me know if I got it
> wrong. :)

In the prototype code, if the profile is only ever copied from Machine A -> Machine B, the server would end up with what would appear to be a series of abandoned histories (each being the last payload submitted by Machine B before having its profile overwritten).  If the profile is also copied from Machine B back to Machine A (and only one machine is used at a time), the history would remain intact.
(In reply to mayankleoboy1 from comment #2)
> I use two Win7 machines with *vastly* different hardware.Both have the same
> profile. Whenever i use the other machine, i copy the complete profile
> folder of the first machine and paste it to the second.

I don't believe copying profile directories is supported by Mozilla. It is risky and may break at any time. You should instead use something like Sync to keep your profiles in sync.

> How would this change the behaviour of the healthreports ? Will the two
> machines generate different healthreport histories on the moz servers , or
> will they be mixed together?

It depends on the sequence of copying and when FHR submits information.

Since copying profiles is not supported and since I'm guessing this practice is not widely employed, I suggest we take no action from FHR to detect it.

If we need to further this discussion, I suggest we open a new bug. This bug has already drifted far enough from its purpose of tracking about:healthreport resetting.
OK. The underlying problem in this bug is that about:healthreport is looking at reporter.willUploadData. This boolean is "upload enabled && data reporting policy accepted." The "opt in" button press only sets the "upload enabled" flag.

If you go to about:healthreport *before* the data reporting policy is accepted via the notification bar, the button press will appear not to stick.

Since about:healthreport seems to display the same notification as the data reporting notification bar, I'm proposing that clicking the button to opt in on about:healthreport will also cause agreement to the data reporting policy.

I will track down the appropriate people to try to get an answer.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I talked to Alex and Tom from Privacy. The default about:healthreport should reflect the "is upload enabled" flag and have no impact on data reporting policy acceptance (just like the pref pane).

I will code up a quick fix.
Assignee: nobody → gps
Status: NEW → ASSIGNED
Whiteboard: [fhr]
Review policy note: While the changed file lives in /browser, the diff is only touching backendy FHR code and no Firefox module members have adequate knowledge of FHR code to grant review.

Patch changes:

* healthReportUploadEnable -> healthReportUploadEnabled typo fix (I should have caught this in original review - doh)
* Query healthReportUploadEnabled instead of willUploadData (we don't want the policy acceptance to influence UX - behaviour of about:healthreport should be the same as prefs according to Privacy)
* Minor style nits in file (while I was here)
Attachment #701980 - Flags: review?(rnewman)
Comment on attachment 701980 [details] [diff] [review]
Unbust about:healthreport, v1

Review of attachment 701980 [details] [diff] [review]:
-----------------------------------------------------------------

Gosh, we need tests for this.

::: browser/base/content/abouthealthreport/abouthealth.js
@@ +26,5 @@
>              .getSelectedLocale("global");
>  }
>  
>  function init() {
> +  refreshWithDataSubmissionFlag(policy.healthReportUploadEnabled);

*bites on cigar*

I LOVE IT WHEN AN ABSTRACTION COMES TOGETHER
Attachment #701980 - Flags: review?(rnewman) → review+
https://hg.mozilla.org/services/services-central/rev/6d3cb2d6873e
OS: Windows 7 → All
Hardware: x86_64 → All
Whiteboard: [fhr] → [fhr][fixed in services]
Comment on attachment 701980 [details] [diff] [review]
Unbust about:healthreport, v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 719484
User impact if declined: about:healthreport won't work
Testing completed (on m-c, etc.): Manual testing of patch
Risk to taking this patch (and alternatives if risky): The alternative is not shipping FHR in 20
String or UUID changes made by this patch: None
Attachment #701980 - Flags: approval-mozilla-aurora?
Comment on attachment 701980 [details] [diff] [review]
Unbust about:healthreport, v1

Approving as we are shipping FHR in Fx20.
Attachment #701980 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/6d3cb2d6873e
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [fhr][fixed in services] → [fhr]
Target Milestone: --- → mozilla21
(In reply to bhavana bajaj [:bajaj] from comment #13)
> Comment on attachment 701980 [details] [diff] [review]
> Unbust about:healthreport, v1
> 
> Approving as we are shipping FHR in Fx20.

Verified fixed in Firefox Aurora 21.0a2 but I don't think I can verify this in Firefox 20.0 Beta since FHR was delayed by one release. Please advise if there's a way to force enable FHR in Firefox 20.
Status: RESOLVED → VERIFIED
Component: Metrics and Firefox Health Report → Client: Desktop
Product: Mozilla Services → Firefox Health Report
Target Milestone: mozilla21 → Firefox 21
Component: Client: Desktop → about:healthreport
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.