Privacy/Docs/How To Triage ETP-Strict Website Breakage

From New wiki
Jump to navigation Jump to search

Steps on how to triage Web Compatibility :: Privacy: Site Reports bugs.

Triage tools:

Triage helper Addon: Site Issue Triage (on Github)

Triage Quick Links

Classification:

Identifying blocked URLs

Identifying the blocked URLs that cause the website to break. In ETP Strict and Private Browsing Mode, multiple third-party tracker resources may be blocked, as the URLClassifier classifies them. However, not every blocked domain could cause the website to break. We need to identify the exact blocked domains that are causing problems for the site. Note that for [1] we don't want to unblock the tracker for the site, but fix the underlying issue in the smartblock shim. Block tp-smartblock-breakage instead.

  1. Start firefox with a clean profile and Anti-Tracking dev-tool panel enabled: ./mach mozregression --launch $(date -d yesterday +%Y-%m-%d) --pref devtools.anti-tracking.enabled:true
  2. Open the devtool panel and click on the "Anti-Tracking" tab
  3. load website and selectively unblock domains that look related or use the interactive debugging

Other options to identify offending tracker

  1. The network monitor panel in DevTools. Sort all network requests by transferred to see all blocked URLs.
  2. The protection panel, which can be opened by clicking the shield icon on the URL bar. Finding all blocked domains on the subpanel of the blocked tracking content.
  3. Use the skipURLs prefs to unblock and verify domains that cause the website to break.

Test different cookie modes

  • Check whether the bug is caused by TCP (Total Cookie Protection): By setting network.cookie.cookieBehavior to 4
  • Check whether it is caused by the soon-to-be-deprecated tracker-cookie-blocking: network.cookie.cookieBehavior.trackerCookieBlocking to false. network.cookie.cookieBehavior has to be 5

Shims breaking websites

Sometimes shims can cause breakage for websites. Go to the "Console" tab of devtools to see which shims are applied to a website. A yellow message such as Google Publisher Tags is being shimmed by Firefox. See https://bugzilla.mozilla.org/show_bug.cgi?id=1713685 for details. gets displayed.

Go to about:compat and disable all applied shims to see whether that unbreaks the website. Look whether there is a bug blocking Bug 1944600 already open. Otherwise open one blocking bug 1944600 and depending on the breakage bug.

about:config

Usually exceptions can be set via urlclassifier.trackingSkipURLs. However, sometimes the tracker is on other lists as well. Use about:url-classifier to see which exception list you need to put the tracking URL and enter the domain in one of these lists:

  • urlclassifier.trackingSkipURLs
  • urlclassifier.features.cryptomining.skipURLs
  • urlclassifier.features.emailtracking.skipURLs
  • urlclassifier.features.fingerprinting.skipURLs
  • urlclassifier.features.socialtracking.skipURLs

The content of the config variable needs to be a list of domains including subdomains: Example: *://*.example.com/*,*://example.com/*,*://sub.example.net/*

Putting diagnosis into bug

After we identify the blocked URLs that cause the website to break, the diagnosis info needs to be updated in the bugs. Therefore, we can use this information to deploy Webcompat exceptions to resolve the issue. Following the steps to put the diagnosis into the bug.

  1. Add the whiteboard tag [privacy-team:diagnosed] to make the bug as diagnosed.
  2. Depending on the WebCompat Classification Criteria to add either [exception-baseline] or [exception-convenience] to the whiteboard.
  3. Add necessary URLs to unblock into the User Story as the format trackers-blocked:xyz.com,*.abc.com.
  4. Add classifier features into the User Story as the format classifier-features:tracking-protection,emailtracking-protection,socialtracking-protection,fingerprinting-protection to indicate which features to unblock. See about:url-classifier for available lists. Usually it is classifier-features:tracking-protection

When reopening bugs due to privious diagnosis not really unbreaking the reported behavior, remove [privacy-team:diagnosed] from the whiteboard to put the bug back into the Needs list of trackers blocked-list

Changing remote settings

Server:

Switching to stage (should be running a clear profile): Install remote-settings-devtools to switch to stage server and test what needs to be tested for the change.

Blocking the correct meta bug

Block the correct meta bug or Bug 1101005 when no meta bug for the breakage exist. There is no hard rule, but when there are 3+ bugs with the same cause it is worth considering opening a meta bug for it. All meta bugs should block bug 1960641 (tp-breakage-metas).

If the bug was caused by tracking protection, you should make sure the bug has the keyword webcompat:tracker-blocking.

List with rough size of meta available under Privacy/Triage/Tp-Breakage

Meta bugs for breakage due to tracking protection with resource blocking:

<bugzilla> { 

 "blocks": "1960641",
 "resolution": "---",
 "keywords": "meta",
 "include_fields": ["id", "summary", "alias", "cc_count"]

} </bugzilla> Meta bugs for breakge of other causes:

<bugzilla> { 

 "query_format": "advanced",
 "product": "Web Compatibility",
 "component": "Privacy: Site Reports",
 "resolution": "---",
 "keywords": "meta",
 "bug_id_type": "nowords",
 "bug_id": "1960641",
 "f1": "blocked",
 "v1": "1960641",
 "o1": "nowords",
 "include_fields": ["id", "summary", "alias", "cc_count"]

} </bugzilla>

Docs

Retrieved from "https://mozilla.mediawiki.site/w/index.php?title=Privacy/Docs/How_To_Triage_ETP-Strict_Website_Breakage&oldid=1256848"