### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Electron Version

13.1.7

### What operating system are you using?

Windows

### Operating System Version

Windows 10 version 20H2

### What arch are you using?

x64

### Last Known Working Electron version

12.0.15

### Expected Behavior

Checking `navigator.userAgentData` in Chrome 91 returns an array of brands appropriately. Electron 13/14 do not return anything.

This appears to then become a problem for my situation. I am posting a form with hidden variables to a third-party vendor I work with. This form post ultimately loads an iframe.

Expected: As it does in Chrome 91, load the iframe from this third-party vendor.

### Actual Behavior

A header of "sec-ch-ua" is included in the request to the third-party vendor and it is blank. They are rejecting the post because of an invalid header. I suspect this is because Chrome 13/14 does not make this hint data made available correctly.

I tried loading various sites in Chrome 91 that do load brand names in Electron 13/14 and they are empty if you review `navigator.userAgentData`.

### Testcase Gist URL

_No response_

### Additional Information

_No response_
shell/browser/api/electron_api_web_contents.cc
It's not safe to assume that |this| points to valid memory at this point.
  if (!weak_this || !ontents())
    return;
   Required to make beforeunload handler work.
  NotifyUserActivation();
}
 TODO(MarshallOfSound): Figure out what we need to do with post data here, I
 believe the default behavior when we pass "true" is to phone out to the
 delegate and then the controller expects this method to be called again with
 "false" if the user approves the reload.  For now this would result in
 ".reload()" calls on POST data domains failing silently.  Passing false would
 result in them succeeding, but reposting which although more correct could be
 considering a breaking change.
void WebContents::Reload() {
  ontents()->GetController().Reload(content::ReloadType::NORMAL,
                                         /* check_for_repost */ true);
}
void WebContents::ReloadIgnoringCache() {
  ontents()->GetController().Reload(content::ReloadType::BYPASSING_CACHE,
                                         /* check_for_repost */ true);
}
void WebContents::DownloadURL(const GURL& url) {
  auto* browser_context = ontents()->GetBrowserContext();
  auto* download_manager = browser_context->GetDownloadManager();
  std::unique_ptr<download::DownloadUrlParameters> download_params(
      content::DownloadRequestUtils::CreateDownloadForWebContentsMainFrame(
          ontents(), url, MISSING_TRAFFIC_ANNOTATION));
  download_manager->DownloadUrl(std::move(download_params));
}
std::u16string WebContents::GetTitle() const {