For #21732 - Adds inactive tabs survey on disable

[codrut-topliceanu]

For #21732

Pull Request checklist

• Tests: This PR includes no tests as it is only a minor change.
• Screenshots: This PR includes screenshots or GIFs of the changes made.
• Accessibility: The code in this PR follows [accessibility best practices](https://github.com/mozilla-mobile/shared-docs/blob/master/android/accessibility_guide.md.

To download an APK when reviewing a PR:

1. click on Show All Checks,
2. click Details next to "Taskcluster (pull_request)" after it appears and then finishes with a green checkmark,
3. click on the "Fenix - assemble" task, then click "Run Artifacts".
4. the APK links should be on the left side of the screen, named for each CPU architecture

[codrut-topliceanu]

Request for data collection review

1. What questions will you answer with this data?

• Why users turn of inactive tabs.

2. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements?


• This data will help understand the usefulness of the feature.

3. What alternative methods did you consider to answer these questions? Why were they not sufficient?


• N/A

4. Can current instrumentation answer these questions?


• No

5. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories found on the Mozilla wiki.

Measurement Description	Data Collection Category	Tracking Bug #
Event: User selected a feedback option	Category 2 “Interaction data”	?

6. Please provide a link to the documentation for this data collection which describes the ultimate data set in a public, complete, and accurate way.

• https://dictionary.telemetry.mozilla.org/apps/fenix

7. How long will this data be collected? Choose one of the following:


• For now the probes are set to expire in 2022-02-01

8. What populations will you measure?


• All users on all release channels

9. If this data collection is default on, what is the opt-out mechanism for users?


• Default Glean SDK opt-out mechanism.

10. Please provide a general description of how you will analyze this data.


• Redash / GLAM

11. Where do you intend to share the results of your analysis?


• Internal with mobile team(s)

12. Is there a third-party tool (i.e. not Telemetry) that you are proposing to use for this data collection?

• No

[MozillaNoah]

why set the text here instead of in the XML?

[codrut-topliceanu]

I needed to send the user's selected feedback back through Glean.

• I couldn't use the actual text on screen as that is dependent on the user's language setting. So no radioButton.text can be used to get the selected feedback.
• I don't know how to get the StringID from a view.
• So I decided to use a map of the StringIDs so that onSEND I can easily get the English text to add to the Glean event.
• But how do I know which StringID correlates to which Radio button? Yeah I know their order and @ids but that's a rename/refactor away from being broken.
• So I wanted a tighter coupling between ViewIDs and StringIDs and went with the mapOf<ViewID, StringID>.
• Now if someone wants to change the string resource of one of the RadioButtons they won't just change in the XML and forget about the .kt file, they will be forced to changed in the .kt file. 😅

Not sure if it's the best solution but 🤷‍♂️

[jonalmeida]

So I wanted a tighter coupling between ViewIDs and StringIDs and went with the mapOf<ViewID, StringID>.

One thing about this approach is if we change the string, the data in the telemetry will show a divergence of options.

Example: The string "I don't understand how it works" changes to "I don't know it works" will mean we start to get two results from the one option.

We could map the options to an internal value that we submit to telemetry (which defeats the problem you were trying to solve). 😕

[codrut-topliceanu]

I suppose that if we ever want to change the strings we should change the Event as well.
Otherwise it will be like running a survey on the street and halfway through you change the answer choices.

[Mugurell]

@MozillaNoah @jonalmeida I plan to finish this after Codrut left so I'm just wondering if I should keep the currently proposed implementation (which I also favor, kinda like having it all in one place, easier to follow) or should I add the string values in xml and then read the text of the selected radio button - infer this in place, don't use the map.

[jonalmeida]

I don't have strong feelings for either solution. 🙂

[travis79]

Request for data collection review

1. What questions will you answer with this data?


* Why users turn of inactive tabs.


1. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements?


* This data will help understand the usefulness of the feature.


1. What alternative methods did you consider to answer these questions? Why were they not sufficient?


* N/A


1. Can current instrumentation answer these questions?


* No


1. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories found on the Mozilla wiki.

Measurement Description Data Collection Category Tracking Bug #
Event: User selected a feedback option Category 2 “Interaction data” ?

1. Please provide a link to the documentation for this data collection which describes the ultimate data set in a public, complete, and accurate way.


* [dictionary.telemetry.mozilla.org/apps/fenix](https://dictionary.telemetry.mozilla.org/apps/fenix)


1. How long will this data be collected? Choose one of the following:


* For now the probes are set to expire in 2022-02-01


1. What populations will you measure?


* All users on all release channels


1. If this data collection is default on, what is the opt-out mechanism for users?


* Default Glean SDK opt-out mechanism.


1. Please provide a general description of how you will analyze this data.


* Redash / GLAM


1. Where do you intend to share the results of your analysis?


* Internal with mobile team(s)


1. Is there a third-party tool (i.e. not Telemetry) that you are proposing to use for this data collection?


* No

Data Review

1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?

Yes, through the metrics.yaml and the Glean Dictionary

2. Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, through the "Send Usage Data" preference in the application settings

3. If the request is for permanent data collection, is there someone who will monitor the data over time?

N/A, collection set to end or be renewed by 2022-02-01

4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 2, Interaction data

5. Is the data collection request for default-on or default-off?

default-on

6. Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?

No

7. Is the data collection covered by the existing Firefox privacy notice?

Yes

8. Does the data collection use a third-party collection tool?

No

Result

data-review+

[travis79]

Please be sure and update the data_sensitivity in the metrics.yaml, as well as the bugs and data_reviews to point at this PR. Thanks!

data-review+

[travis79]

I recommend adding a type, following the example from the Glean docs here:
https://mozilla.github.io/glean/book/reference/metrics/event.html#extra_keys

I will also caution you that the limitation for this extra will truncate the value at 100 UTF8 characters.

[Mugurell]

Added type: string for the extra key.

Currently 100 characters is more than enough but I'll also leave a comment in code about this for the future, thank you!

[Mugurell]

About the type for the extra key:
Seems like with this change the generated code for the extra keys will have them as properties of a data class:

    data class TurnOffInactiveTabsSurveyExtra(
        val feedback: String? = null
    ) : EventExtras {
        override fun toFfiExtra(): Pair<IntArray, List<String>> {
            val keys = mutableListOf<Int>()
            val values = mutableListOf<String>()

            this.feedback?.let {
                keys.add(0)
                values.add(it.toString())
            }
            return Pair(IntArray(keys.size, { keys[it] }), values)
        }
    }

type which is incompatible with what our code expects when parsing the extras - a map.

So atm it would probably be easier to just go with the old way of setting extras - without a type.
Seems like migrating to use the new APIs is planned for #19967

[mergify]

This pull request has conflicts when rebasing. Could you fix it @codrut-topliceanu? 🙏

[Mugurell]

Talked with Kimmy about these changes since there wasn't a DO ticket filed.
She confirmed the telemetry looks good.

[Mugurell]

Rebased and did some small updates to the original PR:

• To ensure we have stable data regarding the number of finished surveys when the user clicks the close button we will be sending the value none as the survey chosen option.
• To prevent user starting the survey then going back from the screen and having the feature disabled without completing the survey the feature will not be disabled automatically when the user taps the switch. Only when the user expressly dismisses the survey by pressing the close button or selects a survey option to send.
• Previously the user could not select an option but press send in which case the survey will close just to reappear the next time the user enables and disabled the feature again. Now the user must select an option for the send button to close the survey.

[Mugurell]

Sorry for asking for a re-review Travis. Not intended. I see the PR still has your approval.

[Mugurell]

Kimmy asked to add a new probe for when the survey shows up.

[Mugurell]

Request for data collection review

1. What questions will you answer with this data?

• When the survey asking users why they intent to disable the inactive tabs feature shows up.

2. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements?


• This data will help understand the usefulness of the feature.

3. What alternative methods did you consider to answer these questions? Why were they not sufficient?


• N/A

4. Can current instrumentation answer these questions?


• No

5. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories found on the Mozilla wiki.

Measurement Description	Data Collection Category	Tracking Bug #
Event: When the survey for why the inactive tabs feature is disabled shows up	Category 2 - “Interaction data”	#21732

6. Please provide a link to the documentation for this data collection which describes the ultimate data set in a public, complete, and accurate way.

• https://dictionary.telemetry.mozilla.org/apps/fenix

7. How long will this data be collected? Choose one of the following:


• For now the probes are set to expire in 2022-02-01

8. What populations will you measure?


• All users on all release channels

9. If this data collection is default on, what is the opt-out mechanism for users?


• Default Glean SDK opt-out mechanism.

10. Please provide a general description of how you will analyze this data.


• Redash / GLAM

11. Where do you intend to share the results of your analysis?


• Internal with mobile team(s)

12. Is there a third-party tool (i.e. not Telemetry) that you are proposing to use for this data collection?

• No

[Mugurell]

@travis79 It seems like there really is need for data-review again.

[travis79]

Request for data collection review

1. What questions will you answer with this data?


* When the survey asking users why they intent to disable the inactive tabs feature shows up.


1. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements?


* This data will help understand the usefulness of the feature.


1. What alternative methods did you consider to answer these questions? Why were they not sufficient?


* N/A


1. Can current instrumentation answer these questions?


* No


1. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories found on the Mozilla wiki.

Measurement Description Data Collection Category Tracking Bug #
Event: When the survey for why the inactive tabs feature is disabled shows up Category 2 - “Interaction data” #21732

1. Please provide a link to the documentation for this data collection which describes the ultimate data set in a public, complete, and accurate way.


* [dictionary.telemetry.mozilla.org/apps/fenix](https://dictionary.telemetry.mozilla.org/apps/fenix)


1. How long will this data be collected? Choose one of the following:


* For now the probes are set to expire in 2022-02-01


1. What populations will you measure?


* All users on all release channels


1. If this data collection is default on, what is the opt-out mechanism for users?


* Default Glean SDK opt-out mechanism.


1. Please provide a general description of how you will analyze this data.


* Redash / GLAM


1. Where do you intend to share the results of your analysis?


* Internal with mobile team(s)


1. Is there a third-party tool (i.e. not Telemetry) that you are proposing to use for this data collection?


* No

Data Review

1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?

Yes, through the metrics.yaml and the Glean Dictionary

2. Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, through the "Send Usage Data" preference in the application settings

3. If the request is for permanent data collection, is there someone who will monitor the data over time?

N/A, collection set to end or be renewed by 2022-02-01

4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 2, Interaction data

5. Is the data collection request for default-on or default-off?

default-on

6. Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?

No

7. Is the data collection covered by the existing Firefox privacy notice?

Yes

8. Does the data collection use a third-party collection tool?

No

Result

data-review+

[travis79]

data-review+ for adding the event

[Mugurell]

Seemingly unrelated ui test failures.
Restarting CI.

[Mugurell]

@Mergifyio backport releases_v94.0.0

[mergify]

backport releases_v94.0.0

✅ Backports have been created

• #22167 For #21732 - Adds inactive tabs survey on disable (backport #21862) has been created for branch releases_v94.0.0