We want to start collecting site breakage reporting for TP in pre-release channels as we allow advanced users to test TP outside PBM. We want to add a conspicuous link to the Control Center TP panel. The test will not be as shown in the (pretty terrible) screenshot, but probably something more along the lines of "Page broken? Tell us about it." We want to understand how often users might notice things like layout breakage, functionality/login issues, etc. and be able to rate them on a level of severity so we can understand what the UX impact could be to general users who may not be as technically savvy. The link will go to a UAG form input that will ideally autopopulate the URL of the page where the user clicked the reporting link. Ideally this is a POST, not a GET, so that the user doesn't get a link in their history that contains the reported page in the query string. The reporting will go into the normal UAG system, but into a different silo than we use for normal user input. This will make it easier to filter and examine the breakage data

I've updated the patch to not display the link in PBM as discussed.

Comment on attachment 8712629 [details] [diff] [review] Patch v2 Review of attachment 8712629 [details] [diff] [review]: ----------------------------------------------------------------- There's some bookkeeping to do, since we're implementing a sub-optimal approach for the sake of expediency, to obtain a sample of data quickly. Since this approach has open issues, I would explicitly limit the link to pre-release channels, adding a preference in about:config that's different from the current Tracking Protection enabled preference. We should have a separate bug on file about making this feature ride the trains (or removing the code if we don't want to do the effort of making it production-ready). We should link to this bug near the #ifdef in the "firefox.js" preferences file. ::: browser/app/profile/firefox.js @@ +1125,5 @@ > #else > pref("app.feedback.baseURL", "https://input.mozilla.org/%LOCALE%/feedback/%APP%/%VERSION%/"); > #endif > +// base URL for web-based feedback page about tracking protection site breakage > +pref("app.feedback.tracking-protection.baseURL", "https://input.mozilla.org/%LOCALE%/feedback/tracking-protection"); "trackingprotection" without dash for consistency with other preference names. ::: browser/base/content/browser-trackingprotection.js @@ +31,5 @@ > gNavigatorBundle.getString("trackingProtection.icon.disabledTooltip"); > > this.enabledHistogramAdd(this.enabledGlobally); > this.disabledPBMHistogramAdd(!this.enabledInPrivateWindows); > + this.reportBreakageAdd(); addReportBreakageLink() or showReportBreakageLink() (The "Add" at the end of the other names refers specifically to the Telemetry histograms.) This shows the link independently of whether there are tracking elements detected. Do you confirm it's what we want? @@ +94,5 @@ > + link.hidden = false; > + link.addEventListener("click", () => { > + let pageUrl = gLastValidURLStr || ""; > + let url = Services.urlFormatter.formatURLPref("app.feedback.tracking-protection.baseURL") + > + "?happy=0&url=" + pageUrl + "#moreinfo"; Seems likely this will break if the URL has "#" in it? Also, please add a comment on the privacy trade-offs. We didn't solve the issue of this URL being included in history, which means the "forget about this site" function would not totally purge a site from history if breakage has been reported for it. We should have a bug on file for this, referenced here. This should block the bug about releasing this feature on all trains. ::: browser/components/controlcenter/content/panel.inc.xul @@ +79,5 @@ > label="&trackingProtection.block2.label;" > accesskey="&trackingProtection.block2.accesskey;" > oncommand="TrackingProtection.enableForCurrentPage();" /> > + > + <label id="tracking-report" tracking-report-breakage

All good suggestions, patch updated. I haven't dealt with the privacy aspect yet, I will start an email thread as discussed.

Reduced in priority to accommodate other priority work.

Move control center bugs, filter on "de-generalize-control-center"

We are now doing this thing in bug 1474238