Display brave:// protocol for internal urls when hovered

[petemill]

Replaces chrome://. This is another unfortunate side effect of us still using chrome:// as the protocol which is neccessary as there are many checks for that string specifically and we're not at a point to change that at the moment. However, this is probably the most visible place remaining where Brave still shows chrome:// and so changing it to brave:// is helpful to avoid confusion.

This was also attempted similarly in #1825 and reverted by #2188, so first I'm seeing which tests fail.

Resolves brave/brave-browser#2566

Submitter Checklist:

• I confirm that no security/privacy review is needed, or that I have requested one
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally: npm run test -- brave_browser_tests, npm run test -- brave_unit_tests, npm run lint, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

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, 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-Protections
  • 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-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

[petemill]

I ran upstream tests since this changes some chromium UI. Looks like upstream tests all passed on macOS, Linux and Android (if applicable?) but some failed on Windows. They seem unrelated

3 tests failed:
17:44:09      MetricIntegrationTest.FirstInputDelay (..\..\chrome\browser\page_load_metrics\integration_tests\first_input_delay_browsertest.cc:17)
17:44:09      PersistedPermissionsFileSystemAccessBrowserTest.UsageIndicatorVisibleWithPersistedPermissionsEnabled (..\..\chrome\browser\ui\views\file_system_access\file_system_access_browsertest.cc:804)
17:44:09      WebAppTabStripBrowserTest.OnlyNavigateHomeTabIfDifferentUrl (..\..\chrome\browser\ui\views\web_apps\web_app_tab_strip_browsertest.cc:494)

[sangwoo108]

One of error looks interesting

Terminating render process for bad Mojo message: Received bad user message: No binder found for interface brave_news.mojom.BraveNewsController for the frame/document scope

[sangwoo108]

LGTM 👍

[sangwoo108]

Could it be worth replacing 'chrome-untrusted' too?

[petemill]

I'm not so sure about that because chrome-untrusted is never meant to be displayed to users

[simonhong]

++ 👍🏼 It would be nice to have a test case for this :)

[petemill]

++ 👍🏼 It would be nice to have a test case for this :)

@simonhong Yes to be honest I was surprised that there weren't more existing test failures as I think you tried this in a previous PR but reverted or didn't merge?

[simonhong]

++ 👍🏼 It would be nice to have a test case for this :)

@simonhong Yes to be honest I was surprised that there weren't more existing test failures as I think you tried this in a previous PR but reverted or didn't merge?

Not sure but maybe it would be possible that my previous PR was not the cause of test failure at that time.

[petemill]

++ 👍🏼 It would be nice to have a test case for this :)

I looked in to adding a test for this, probably in brave_browser_browsertest.cc. The problem is that the GURL is passed to StatusBubbleViews::StatusView which does not provide a public API to read the value back. There aren't even any tests to check the set url in chromium. If anyone has a suggestion on a clean way to read this back then I'll consider it. Otherwise I could move the GURL-modifying code in to a testable static util function, but it seems to simple to need a test.

[simonhong]

++ 👍🏼 It would be nice to have a test case for this :)

I looked in to adding a test for this, probably in brave_browser_browsertest.cc. The problem is that the GURL is passed to StatusBubbleViews::StatusView which does not provide a public API to read the value back. There aren't even any tests to check the set url in chromium. If anyone has a suggestion on a clean way to read this back then I'll consider it. Otherwise I could move the GURL-modifying code in to a testable static util function, but it seems to simple to need a test.

Ok, let's go with current PR :)