detector service for breakage reporting

[jdorweiler]

Asana Task/Github Issue: https://app.asana.com/1/137249556945/project/72649045549333/task/1211666118504301?focus=true

Description

Building on #2048 with a more generalize framework for breakage reports.

New detector service:

• Registry + caching with configurable TTL
• Auto-registration from remote config during page load
• Optional auto-run with configurable delay (default 100ms)
• Domain gating + custom shouldRun() checks (only during auto-run)
• Multi-consumer design (any feature can import and use)

Changed:

• Architecture: Service with dynamic registration
• Caching: Built-in with TTL vs re-scan every call
• Configuration: Remote config vs function parameters
• Lifecycle: Auto-registers on page load + optional auto-run vs on-demand only
• Gating: Domain restrictions + custom checks
• Consumers: Any feature can use service

See the injected/src/detectors/README.md for more details

Testing Steps

Checklist

Please tick all that apply:

• I have tested this change locally
• I have tested this change locally in all supported browsers
• This change will be visible to users
• I have added automated tests that cover this change
• I have ensured the change is gated by config
• This change was covered by a ship review
• This change was covered by a tech design
• Any dependent config has been merged

---

Note

Introduce on-demand bot/fraud detectors and wire them into breakage reporting, enable new feature across platforms, and add integration tests with mock pages.

• Detectors:
  • Add on-demand utilities runBotDetection and runFraudDetection with shared helpers in injected/src/detectors/** and fallback default-config.
  • New feature wrapper injected/src/features/web-interference-detection.js exposing detectInterference via messaging.
• Breakage Reporting:
  • Enhance injected/src/features/breakage-reporting.js to optionally include detectorData using webInterferenceDetection settings.
• Feature Enablement:
  • Register webInterferenceDetection in injected/src/features.js and enable on apple, android, windows, chrome, and chrome-mv3.
• Tests & Pages:
  • Expand injected/integration-test/breakage-reporting.spec.js with cases for clean page, Cloudflare, reCAPTCHA, and PerimeterX.
  • Add test config enabling detectors and mock pages under injected/integration-test/test-pages/breakage-reporting/**.

^{Written by Cursor Bugbot for commit 7d8619c. This will update automatically on new commits. Configure here.}

[netlify]

✅ Deploy Preview for content-scope-scripts ready!

Name	Link
🔨 Latest commit	7d8619c
🔍 Latest deploy log	https://app.netlify.com/projects/content-scope-scripts/deploys/692083b80a1f9d00086ea5be
😎 Deploy Preview	https://deploy-preview-2052--content-scope-scripts.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[github-actions]

Temporary Branch Update

The temporary branch has been updated with the latest changes. Below are the details:

• Branch Name: pr-releases/pr-2052
• Commit Hash: 17e5dc05454134151ca83ca51959de851ad2a833
• Last Updated: November 21, 2025 at 3:23:17 PM UTC
• Install Command: npm i github:duckduckgo/content-scope-scripts#17e5dc05454134151ca83ca51959de851ad2a833

Please use the above install command to update to the latest version.

[github-actions]

[Beta] Generated file diff

Time updated: Fri, 21 Nov 2025 15:23:31 GMT

Android

    - android/adsjsContentScope.js

• android/autofillImport.js
• android/brokerProtection.js
• android/contentScope.js

File has changed

Apple

    - apple/contentScope.js

• apple/contentScopeIsolated.js

File has changed

Chrome-mv3

    - chrome-mv3/inject.js

File has changed

Firefox

    - firefox/inject.js

File has changed

Integration

    - integration/contentScope.js

File has changed

Windows

    - windows/contentScope.js

File has changed

[madblex]

This looks great. I added some comments and a couple more here:

1. I'd like to see how this integrates with content features, especially broker protection, i.e. the equivalent of this
2. I see we removed WebInterferenceDetection content feature. Is it because you don't think we'll need a standalone feature for this? i.e. the detectors will only be called from other features.
3. I see we're going the functional route (from classes). Not feeling strongly (I prefer functional most of the time), I just believe the trade-off is that interfaces will be more difficult to enforce. I think classes provide a bit of a better structure, but this is opinionated.

[jdorweiler]

This looks great. I added some comments and a couple more here:

1. I'd like to see how this integrates with content features, especially broker protection, i.e. the equivalent of [this](https://github.com/duckduckgo/content-scope-scripts/pull/2048/files#r2513656558)

2. I see we removed `WebInterferenceDetection` content feature. Is it because you don't think we'll need a standalone feature for this? i.e. the detectors will **only** be called from other features.

3. I see we're going the functional route (from classes). Not feeling strongly (I prefer functional most of the time), I just believe the trade-off is that interfaces will be more difficult to enforce. I think classes provide a bit of a better structure, but this is opinionated.

1. Commented here https://github.com/duckduckgo/content-scope-scripts/pull/2048/files#r2514564110
2. Yeah, I changed it so detectors auto register via detector-init.js during the load phase, and features import the service directly. So detector initialization is handled for you. Then you just need to add the message handler to broker protection (see my comment linked in 1)
3. I'm not strongly attached to this approach. I wanted to see what functional approach looked like vs classes but I'm open to switching to classes if you think the structure is worth it.

[madblex]

This looks great. I added some comments and a couple more here:

1. I'd like to see how this integrates with content features, especially broker protection, i.e. the equivalent of [this](https://github.com/duckduckgo/content-scope-scripts/pull/2048/files#r2513656558)

2. I see we removed `WebInterferenceDetection` content feature. Is it because you don't think we'll need a standalone feature for this? i.e. the detectors will **only** be called from other features.

3. I see we're going the functional route (from classes). Not feeling strongly (I prefer functional most of the time), I just believe the trade-off is that interfaces will be more difficult to enforce. I think classes provide a bit of a better structure, but this is opinionated.

1. Commented here https://github.com/duckduckgo/content-scope-scripts/pull/2048/files#r2514564110
2. Yeah, I changed it so detectors auto register via detector-init.js during the load phase, and features import the service directly. So detector initialization is handled for you. Then you just need to add the message handler to broker protection (see my comment linked in 1)
3. I'm not strongly attached to this approach. I wanted to see what functional approach looked like vs classes but I'm open to switching to classes if you think the structure is worth it.

1. 👍
2. Fine for me. We can always add a dedicated feature later if needed
3. No need to do the extra work. This will likely work fine as well. Thanks.

[jdorweiler]

@jonathanKingston Thanks for the review. I refactored this into a WebInterferenceDetection ContentFeature, got rid of the standalone service/init, and switched to using getFeatureSetting() conditionalChanges for config. Let me know what you think.