943386 - Disabled health report, still attempting to send

Status: RESOLVED INVALID

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

Description

[Bernie Rataj]

Attachment: healthreport-settings.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910201120

Steps to reproduce:

Disabled all reporting in Tools > Options > Advanced > Data Choices.


Actual results:

Daily Firefox makes several attempts to contact fhr-data-zlb.vips.scl3.mozilla.com.

about:config shows datareporting.healthreport.uploadEnabled is false, but datareporting.healthreport.currentDaySubmissionFailureCount increments, and the datareporting.healthreport.lastDataSubmissionFailureTime matches the popups I get from the BlueCoat software that denies the access.


Expected results:

Health report should not be sent.

Comment 1

[:Gijs (he/him)]

Have you checked what kind of requests it's sending? FHR will attempt to delete reported data once you turn it off, AIUI from bug 941113.

Comment 2

[Bernie Rataj]

Reviewed bug 941113... have not checked what kind of request is being sent, but it is perhaps moot.

The BlueCoat setup is such that it now disallows ALL access, apparently after some health data had already been sent; this is putting us in the position of several times daily not being able to delete existing health data.

Not clear if this should be addressed by Firefox or our BlueCoat folks.

Comment 3

[:Gijs (he/him)]

(In reply to Bernie Rataj from comment #2)
> Not clear if this should be addressed by Firefox or our BlueCoat folks.

I don't know the answer to that question, but let's at least move this to FHR.

Comment 4

[Richard Newman [:rnewman]]

Firefox on desktop will never give up trying to delete the data you already uploaded. Filed Bug 943454 for this.

The easiest workaround is to temporarily allow access, wait a day or two, then block again.

(If your organization has a policy restricting access like this, you should also configure Firefox in advance so you don't get into this state! So it goes.)

The general scenario in which users encounter this is in changing locations, going on vacation, captive portals, etc., so even if we limit the number of attempts, that limit will be on the order of a month or so. The alternative would be that an opted-out user's data sticks around in FHR, which doesn't serve anyone's needs.

I'm going to mark this as INVALID, because this is the expected behavior, but see that dependent bug for a small change in behavior.