Remote debugging can now be enabled via brave://settings/privacy

[bsclifton]

Remote debugging can now be enabled via brave://settings/privacy

• Default for this is FALSE (meaning remote debugging is disabled).
• Setting is global (using local_state), not per-profile.

Fixes brave/brave-browser#5640
Fixes brave/brave-browser#3199

NOTE: if this is merged, I will need to update https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)

Submitter Checklist:

• Submitted a ticket for my issue if one did not already exist.
• Used Github auto-closing keywords in the commit message.
• Added/updated tests for this change (for new code or code which already has tests).
• Verified that these changes build without errors on
  • Android
  • iOS
  • Linux
  • macOS
  • Windows
• Verified that these changes pass automated tests (unit, browser, security tests) on
  • iOS
  • Linux
  • macOS
  • Windows
• Verified that all lint errors/warnings are resolved (npm run lint)
• Ran git rebase master (if needed).
• Ran git rebase -i to squash commits (if needed).
• Tagged reviewers and labelled the pull request as needed.
• Request a security/privacy review as needed.
• Add appropriate QA labels (QA/Yes or QA/No) to include the closed issue in milestone
• Public documentation has been updated as necessary. For instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protection-Mode
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Custom-Headers
  • https://github.com/brave/brave-browser/wiki/Web-compatibility-issues-with-tracking-protection
  • https://github.com/brave/brave-browser/wiki/QA-Guide

Test Plan:

Test remote debugging feature (brave/brave-browser#5640)

1. New profile
2. Connect Android device to Desktop
3. Open brave://inspect#devices in Desktop
4. Visit a site on brave Android
5. Ensure the site lists on brave://inspect#devices
6. Click on inspect under the device name in desktop
7. Developer tool window launches but never loads
8. Quit Brave and relaunch
9. Visit brave://settings/privacy
10. Enable Remote debugging (it should have been turned off)
11. With device still attached, visit a site on brave Android
12. Click on inspect under the device name in desktop
13. Developer tool window launches
14. It should work 🎉

Test Lighthouse (brave/brave-browser#3199)

1. New profile
2. Launch Brave from command line (so you can see stdout)
3. Visit https://clifton.io
4. Open developer tools (F12 / Cmd+Opt+I)
5. Open Audits
6. Click Run audits
7. stdout should output Remote debugging is DISABLED. If you want to use it, please enable in brave://settings/privacy (may show 2 or 3 times)
8. Verify that Audit gets stuck
9. Quit Brave and relaunch
10. Visit brave://settings/privacy
11. Enable Remote debugging (it should have been turned off)
12. Visit https://clifton.io
13. Open developer tools (F12 / Cmd+Opt+I)
14. Open Audits
15. Click Run audits
16. Lighthouse functionality should work 🎉

Reviewer Checklist:

• New files have MPL-2.0 license header.
• Request a security/privacy review as needed.
• Adequate test coverage exists to prevent regressions
• Verify test plan is specified in PR before merging to source

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on.
• All relevant documentation has been updated.

[bsclifton]

@rebron this section is getting a bit crowded- we have an opportunity to maybe have a Brave specific section... maybe something like Optional features, Extended Privacy, Services that reach out, etc

If there was a new area, that would be where this setting, P3A, Push Messaging, WebRTC, and other coming soon settings (like disabling autocomplete, disabling tor) could live. Basically leaving the Chromium ones alone

[simonhong]

It would be good if settings change can be synced across multiple settings page.

[rebron]

Let's go with Remote debugging and current placement for now, we need to redesign this section and make it more user friendly.

[bsclifton]

Text updated, security review approved! 🎉

[jumde]

enabling remote debugging sends requests to google, are we okay not proxying those requests?

[bsclifton]

@jumde since it's opt-in, this approach is OK and was security review approved. But I do think we can create an enhancement to proxy that in the future

Also: there was a lint error (my bad) - just checked in a fix for that. Otherwise, all CI passed 🎉

[bsclifton]

@simonhong do you mean for the scenario where multiple windows with different profiles are open? (and setting is updated in one?)

[simonhong]

@bsclifton For this prefs, profiles are not important because it's local state.
If I opened multiple settings page(same profile or not) and I changed this settings in one window, other settings page should show same newly changed option value.
(If profile prefs are used, this is done w/o dev effort for same profile's windows.)

[bsclifton]

@simonhong ah- yes, I forgot you can manually open more instances of settings (if you keep trying via hamburger, it opens an already existing one)

[simonhong]

Yes, we can open many settings pages. but I think it is not the blocker for this PR :)

[bsclifton]

Updated PR to cover the multiple window scenario (also, fixed this for P3A which was missing this too). Tested locally on macOS w/ Debug/Release. Rebased and CI running again.

[bsclifton]

Only failure was on iOS compilation (which was fixed/merged in master with #4070). I'll label accordingly, rebase, and restart CI

[bsclifton]

There we go- after rebase, iOS looks good 🎉

[bsclifton]

Forgot to update documentation! Doing that now 😄

[bsclifton]

updated!

[bsclifton]

Possibly also fixed brave/brave-browser#5618 when this landed