Closed Bug 1240064 Opened 9 years ago Closed 6 years ago

[experiment] Add a link to report site breakage in TP panel in Control Center

Categories

(Firefox :: Site Identity, defect, P3)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1474238

People

(Reporter: javaun, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fxprivacy])

Attachments

(2 files, 2 obsolete files)

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
Whiteboard: [fxprivacy]
Blocks: 1219353
Flags: qe-verify?
Priority: -- → P2
Attached patch Patch v1 (obsolete) (deleted) — Splinter Review
Assignee: nobody → past
Status: NEW → ASSIGNED
Flags: qe-verify? → qe-verify+
Iteration: --- → 46.3 - Jan 25
Priority: P2 → P1
Assignee: past → nobody
Status: ASSIGNED → NEW
Iteration: 46.3 - Jan 25 → ---
Priority: P1 → P4
Assignee: nobody → past
Status: NEW → ASSIGNED
Iteration: --- → 47.1 - Feb 8
Priority: P4 → P1
Summary: Add a link to report site breakage in TP panel in Control Center → [experiment] Add a link to report site breakage in TP panel in Control Center
Blocks: 1241523
No longer blocks: 1219353
Attached patch Patch v2 (obsolete) (deleted) — Splinter Review
I've updated the patch to not display the link in PBM as discussed.
Attachment #8712629 - Flags: review?(paolo.mozmail)
Attachment #8708453 - Attachment is obsolete: true
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
Attachment #8712629 - Flags: review?(paolo.mozmail)
Attached patch Patch v3 (deleted) — Splinter Review
All good suggestions, patch updated. I haven't dealt with the privacy aspect yet, I will start an email thread as discussed.
Attachment #8712629 - Attachment is obsolete: true
Iteration: 47.1 - Feb 8 → 47.2 - Feb 22
Iteration: 47.2 - Feb 22 → 47.3 - Mar 7
Reduced in priority to accommodate other priority work.
Assignee: past → nobody
Status: ASSIGNED → NEW
Iteration: 47.3 - Mar 7 → ---
Priority: P1 → P3
Move control center bugs, filter on "de-generalize-control-center"
Component: General → Site Identity and Permission Panels
We are now doing this thing in bug 1474238
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: