about:healthreport resets everytime you close that tab

VERIFIED FIXED in Firefox 20

Status

Firefox Health Report
Web: Health Report
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Mayank Bansal, Assigned: gps)

Tracking

unspecified
Firefox 21
Points:
---

Firefox Tracking Flags

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

Details

(Whiteboard: [fhr], URL)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
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
(Reporter)

Comment 2

5 years ago
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?
(Assignee)

Updated

5 years ago
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.

Comment 5

5 years ago
(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.
(Assignee)

Comment 6

5 years ago
(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.
(Assignee)

Comment 7

5 years ago
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
(Assignee)

Comment 8

5 years ago
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
(Assignee)

Updated

5 years ago
status-firefox18: --- → unaffected
status-firefox19: --- → unaffected
status-firefox20: --- → affected
status-firefox21: --- → affected
(Assignee)

Updated

5 years ago
Whiteboard: [fhr]
(Assignee)

Comment 9

5 years ago
Created attachment 701980 [details] [diff] [review]
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)
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+
(Assignee)

Comment 11

5 years ago
https://hg.mozilla.org/services/services-central/rev/6d3cb2d6873e
OS: Windows 7 → All
Hardware: x86_64 → All
Whiteboard: [fhr] → [fhr][fixed in services]
(Assignee)

Comment 12

5 years ago
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?

Updated

5 years ago
tracking-firefox20: --- → +
tracking-firefox21: --- → +
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+
(Assignee)

Comment 14

5 years ago
https://hg.mozilla.org/mozilla-central/rev/6d3cb2d6873e
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
status-firefox21: affected → fixed
Resolution: --- → FIXED
Whiteboard: [fhr][fixed in services] → [fhr]
Target Milestone: --- → mozilla21

Comment 15

5 years ago
Pushed to Aurora:
http://hg.mozilla.org/releases/mozilla-aurora/rev/5037fa98b378
status-firefox20: affected → fixed
(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
status-firefox21: fixed → verified

Updated

5 years ago
Component: Metrics and Firefox Health Report → Client: Desktop
Product: Mozilla Services → Firefox Health Report
Target Milestone: mozilla21 → Firefox 21

Updated

5 years ago
Component: Client: Desktop → about:healthreport
You need to log in before you can comment on or make changes to this bug.