bug 1714939 is going to add new pref for popup handling, that partially overlaps with old browser.link.open_newwindow.restriction pref, and the patch there is going to remove it, to simplify the behavior and avoid edge case.

we should verify that browser.link.open_newwindow.restriction pref isn't much used with custom value.

If the pref is widely used, we should reconsider the new pref, maybe by extending browser.link.open_newwindow.restriction pref instead to cover the new behavior.

note, and things to consider:

• browser.link.open_newwindow.restriction is numeric pref, that takes 0, 1, or 2
• browser.link.open_newwindow.restriction has different default value for desktop (2) and mobile (0)
• we might not have to collect numbers of default value usage, if we have other reliable number to compare

given the pref has almost no effect on mobile (given no tab/window distinction), collecting the data only for desktop should be sufficient.

Comment on attachment 9250219 [details]
Data collection request

PRELIMINARY NOTES:
Please use the data-review flag instead of the review flag for future Data Review Requests.

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes.

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

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

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

No. This collection will expire in Firefox 97.

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

Category 1, Technical.

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

Default on for all channels.

Does the instrumentation include the addition of any new identifiers?

No.

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

Yes.

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

No.

Result: datareview+

https://hg.mozilla.org/mozilla-central/rev/5a41528d9187

Comment on attachment 9250226 [details]
Bug 1740063 - Collect telemetry for hidden browser.link.open_newwindow.restriction preference usage. r?chutten!

Beta/Release Uplift Approval Request

• User impact if declined: None
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This adds a simple telemetry probe for recording a preference value with Glean, in the same way as bug 1715129.
• String changes made/needed:

This patch does not graft to beta.

Do you mean the patch has conflict?
I don't see any conflict against dcbd9ffedd9e.
mp patch -a . D130887 works without any problem on dcbd9ffedd9e.

hg graft -er 5a41528d9187
grafting 686420:5a41528d9187 "Bug 1740063 - Collect telemetry for hidden browser.link.open_newwindow.restriction preference usage. r=chutten"
merging browser/components/BrowserGlue.jsm
merging browser/components/tests/unit/xpcshell.ini
warning: conflicts while merging browser/components/BrowserGlue.jsm! (edit, then use 'hg resolve --mark')
abort: unresolved conflicts, can't continue
(use 'hg resolve' and 'hg graft --continue'

Importing the patch seems to work with hg import -e <(hg phabread D130887)

Comment on attachment 9250226 [details]
Bug 1740063 - Collect telemetry for hidden browser.link.open_newwindow.restriction preference usage. r?chutten!

Approved for our last 95 beta.

https://hg.mozilla.org/releases/mozilla-beta/rev/b4588bb55ef7