829953 - about:healthreport resets everytime you close that tab

Status: VERIFIED FIXED

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

Description

[Mayank Bansal]

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.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

In Addition datareporting.healthreport.service.enabled;true + the Checkmark in the UI (Options/Advanced/Data Choices) is set properly.

Comment 2

[Mayank Bansal]

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?

Comment 3

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

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!

Comment 4

[Daniel Einspanjer [:dre] [:deinspanjer]]

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

Comment 5

[Mark Reid [:mreid]]

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

Comment 6

[Gregory Szorc [:gps]]

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

Comment 7

[Gregory Szorc [:gps]]

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.

Comment 8

[Gregory Szorc [:gps]]

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.

Comment 9

[Gregory Szorc [:gps]]

Attachment: Unbust about:healthreport, v1

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)

Comment 10

[Richard Newman [: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

Comment 11

[Gregory Szorc [:gps]]

https://hg.mozilla.org/services/services-central/rev/6d3cb2d6873e

Comment 12

[Gregory Szorc [:gps]]

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

Comment 13

[bhavana bajaj [:bajaj]]

Comment on attachment 701980 [details] [diff] [review]
Unbust about:healthreport, v1

Approving as we are shipping FHR in Fx20.

Comment 14

[Gregory Szorc [:gps]]

https://hg.mozilla.org/mozilla-central/rev/6d3cb2d6873e

Comment 15

[Scoobidiver (away)]

Pushed to Aurora:
http://hg.mozilla.org/releases/mozilla-aurora/rev/5037fa98b378

Comment 16

[u279076]

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