697860 - Hide close button in the telemetry notification, and track explicit clicks on "no"

Status: VERIFIED FIXED

(Toolkit :: Telemetry, defect)

Description

[(dormant account)]

We should track the difference between clicking "no" and "x" in telemetry prompt.

Comment 1

[(dormant account)]

Attachment: store prompt response

Comment 2

[(dormant account)]

Comment on attachment 570397 [details] [diff] [review]
store prompt response

This will reprompt users with old prompt and record their answer to telemetry. Unfortunately nightly users will be reprompted again because of change how the pref is used(such is the cost of being a nightly user).

Comment 3

[(dormant account)]

This patch will use telemetry.prompted to store a tristate to indicate whether the users chose(Yes/No/[x]) where clicking [x] == ignoring the prompt.

Comment 4

[(dormant account)]

ping gavin?

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 570397 [details] [diff] [review]
store prompt response

Let's leave the TELEMETRY_PROMPT_REV stuff as-is and go with a new telemetry.denied pref as discussed on IRC.

Comment 6

[(dormant account)]

Attachment: v2

Comment 7

[(dormant account)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/1592d3bec85b

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

https://hg.mozilla.org/mozilla-central/rev/1592d3bec85b

Comment 9

[(dormant account)]

http://hg.mozilla.org/releases/mozilla-beta/rev/c3699adea043

Comment 11

[al_9x]

(In reply to Taras Glek (:taras) from comment #6)
> Created attachment 571698 [details] [diff] [review] [diff] [details] [review]
> v2

shouldn't PREF_TELEMETRY_REJECTED be checked, to return and avoid the prompt?

Comment 12

[(dormant account)]

(In reply to al_9x from comment #11)
> (In reply to Taras Glek (:taras) from comment #6)
> > Created attachment 571698 [details] [diff] [review] [diff] [details] [review] [diff] [details] [review]
> > v2
> 
> shouldn't PREF_TELEMETRY_REJECTED be checked, to return and avoid the prompt?

It will be if we ever add code to reprompt(ie bump telemetry prompt version). Atm there is no such code, thus no check. Previous prompting code did not indicate if the user clicked no, so we had to reprompt.

Comment 13

[u279076]

QA+ for verification using comment 3.

Comment 14

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (Windows NT 6.1; rv:11.0a1) Gecko/20111205 Firefox/11.0a1

The first notification prompt received with a new profile doesn't have a tri-state unless selecting "Learn more". Is this expected?

When selecting "NO" the toolkit.telemetry.rejected pref is set to true in about:config. With "yes" and "x" the pref is not displayed.

Should the notification ever re-prompt if ignoring it with "x"?

Would appreciate any feedback in order to verify this. Thanks.

Comment 15

[Lawrence Mandel [:lmandel] (use needinfo)]

The tri-state should function as follows:

Click yes
- the user opts in to Telemetry
- toolkit.telemetry.enabled=true
- no further prompting
Click no
- the user opts out of Telemetry
- toolkit.telemetry.enabled=false
- toolkit.telemetry.rejected=true (?)
- no further prompting
Click x
- the user has not made a Telemetry choice (neither yes nor no)
- toolkit.telemetry.prompted= (?)
- further prompting (at some interval) until the user makes a choice

Taras - Can you help me fill in the (?)?

Comment 16

[:Gavin Sharp [email: [e-mail]]]

I'm re-summarizing this bug to cover what was actually done. The patch here disables the close button on the notification completely.

The expected behavior is:

The notification having been displayed sets toolkit.telemetry.prompted to true.
- User clicking "yes" sets toolkit.telemetry.enabled to true
- User clicking "no" sets toolkit.telemetry.rejected to true

Comment 17

[:Gavin Sharp [email: [e-mail]]]

(In reply to Gavin Sharp from comment #16)
> The notification having been displayed sets toolkit.telemetry.prompted to
> true.

This isn't quite accurate: it sets .prompted to the current "prompt rev" (currently 2). If the .prompted pref matches the current prompt rev, we do not prompt. This allows us to force reprompting in the future by changing the prompt rev constant.

Comment 18

[Lawrence Mandel [:lmandel] (use needinfo)]

Can the notification be dismissed without clicking yes or no?

Comment 19

[Virgil Dicu [:virgil] [QA]]

Thank you for the feedback.

The Close button (x) is still displayed in the notification if selecting "Learn more" (privacy policy). Is this expected?

As of the rest, I can confirm the behavior specified in comment 15 with the additions from comment 16, 17:

Clicking yes: toolkit.telemetry.enabled=true
Clicking no: toolkit.telemetry.enabled=false and toolkit.telemetry.rejected=true
Clicking x: toolkit.telemetry.enabled=false 

toolkit.telemetry.prompted is set to "2" regardless of the option chosen in the notification.

(In reply to Lawrence Mandel [:lmandel] from comment #18)
> Can the notification be dismissed without clicking yes or no?

From my experience, apart from closing the notification within the privacy policy, the only way to close it is to close the tab.

Comment 20

[:Gavin Sharp [email: [e-mail]]]

(In reply to Virgil Dicu [QA] from comment #19)
> the only way to close it is to close the tab.

That's correct.

Comment 21

[u279076]

Virgil can you please verify if this is fixed on Beta given your testing so far?

Comment 22

[Virgil Dicu [:virgil] [QA]]

I specified and asked this in previous comments: the Close button (x) is still displayed in the notification if selecting "Learn more" (privacy policy).

I filed a bug for this: bug 710589. If it's intended that can be set to Invalid.

Comment 23

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0

The rest works as expected, as specified in comment 19:
Clicking yes: toolkit.telemetry.enabled=true
Clicking no: toolkit.telemetry.enabled=false and toolkit.telemetry.rejected=true
Clicking x: toolkit.telemetry.enabled=false 

I've only let this go for the answer to the problem which I now reported in bug 710589. Setting thus to verified for beta.

Comment 24

[Mike Kaply [:mkaply]]

This was a bad change. The pref should have been renamed.

It's causing an error for enterprises that were setting it to to true in their config files to prevent it from being shown to users.

Comment 25

[Mike Kaply [:mkaply]]

For people that don't know about this feature:

https://developer.mozilla.org/en/Automatic_Mozilla_Configurator/Locked_config_settings

Comment 26

[Saul]

While upgrading from Firefox 8 to 9, upon first launch an error appears with the following text,

AutoConfig Alert
Netscape.cfg/AutoConfig failed. Please contact your system administrator.
Error: defaultPref failed: [Exception... "Component returned failure code 0x8000ffff
(NS_ERROR_UNEXPECTED) [nsIPrefBranch.SetIntPref]" nsresult: "0x8000ffff
(NS_ERROR_UNEXPECTED)" location: "JS fram :: prefcalls.js :: defaultPref "" line 88" data: no]

This error is self correcting and does not re-occur. 

This error is related to the type change between Firefox version 8 and 9 as follows:
Prior to Firefox 9:
user_pref("toolkit.telemetry.prompted", true);
 
Firefox 9:
user_pref("toolkit.telemetry.prompted", 2);

The above setting is located under the user's profile in the prefs.js file. Following the error, the prefs.js file is updated to use the integer type. (hence self-correction)

To reproduce the error, the installation needs to be configured for the Locked Config Settings (mozilla.cfg) with the following parameter specified. 
                       lockPref("toolkit.telemetry.prompted", 2)

Comment 27

[(dormant account)]

(In reply to Michael Kaply (mkaply) from comment #25)
> For people that don't know about this feature:
> 
> https://developer.mozilla.org/en/Automatic_Mozilla_Configurator/
> Locked_config_settings

I didn't know about this. I can't access the page atm, but i guess the fix is to update the pref in the configurator.

Comment 28

[Mike Kaply [:mkaply]]

> I didn't know about this. I can't access the page atm, but i guess the fix is to update the pref in the configurator.

No, the correct fix is to revert the change and not turn a boolean pref into an int.

The problem is that a situation is created now where configuration file that worked on FF 8 and below don't work at 9.

In addition, this change would break any add-on that was setting or querying that preference.

Changing a preference from one type to another is generally a bad idea.

Comment 29

[(dormant account)]

Michael, I can see your point, but this didn't come up during beta testing and now that this is released it's not possible to change it back without reprompting every firefox user again.

Comment 30

[Mike Kaply [:mkaply]]

Well I hope someone makes a note somewhere that changing a preference from one type to another is never a good idea. And it certainly should have been documented somewhere for add-on authors which would have caused someone to notice it.

Unfortunately there's no good way to fix this problem so that it works on Firefox 8 and 9. We could add a try catch in autoconfig to prevent the popup, but we're still left with the fact that users will be prompted for telemetry when companies do not want them to be prompted.

Comment 31

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20100101 Firefox/10.0

This works as specified in comment 23 for Firefox 10 beta 1 too. Setting resolution to Verified Fixed.

Clicking yes: toolkit.telemetry.enabled=true
Clicking no: toolkit.telemetry.enabled=false and toolkit.telemetry.rejected=true
Clicking x: toolkit.telemetry.enabled=false