13778: Avoid crash while getting an accessibility string.

[iefremov]

For some reason, MacOS call the patched method for tabs,
and tabs cannot provide an accessibility string.

Fix brave/brave-browser#13778

Resolves

Submitter Checklist:

• There is a ticket for my issue.
• Used Github auto-closing keywords in the commit message.
• Wrote a good PR/commit description
• 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).
• Requested a security/privacy review as needed.

Reviewer Checklist:

• 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:

[simonhong]

Below method calls same one. Then, crash can occur with this?

- (id)AXStringForRange:(id)parameter {
  DCHECK([parameter isKindOfClass:[NSValue class]]);
  return [[self getAXValueAsString] substringWithRange:[parameter rangeValue]];
}

[iefremov]

@simonhong AFAIK, objective C allows to call methods of nil object, so in this particular case we are safe even if getAXValueAsString returns nil.

Apparently there are many dangerous spots (since the whole file has been a WIP for a long time), but I'm not sure whether we should patch anything else until it bothers us

[bridiver]

please make sure we have a follow-up issue to investigate this and there are also some crashes for substring out of range

[iefremov]

Follow-up brave/brave-browser#13802

[iefremov]

CI failures unrelated

[petemill]

Does this fix these issues which happen for all signed official builds and crash PWA windows with the following error?

-[NSAccessibilityRemoteUIElement accessibilityTitle]: unrecognized selector sent to instance 0x7fe0a0eadbe0

brave/brave-browser#8117
brave/brave-browser#7205

[iefremov]

Does this fix these issues which happen for all signed official builds and crash PWA windows with the following error?

unfortunately, it doesn't

[LaurenWags]

Attempted to verify using

Brave | 1.21.35 Chromium: 88.0.4324.96 (Official Build) nightly (x86_64)
-- | --
Revision | 68dba2d8a0b149a1d3afac56fa74648032bcf46b-refs/branch-heads/4324@{#1784}
OS | macOS Version 10.15.7 (Build 19H15)

Reproduced the issue multiple times using steps and version listed in brave/brave-browser#13778 (comment) (1.21.30).

Executed those same steps using 1.21.35 and was eventually able to reproduce the crash. It took a bit longer, but it was reproducible using the same steps. Crash report id: a81a0000-9cc8-c705-0000-000000000000

Per discussion with @kjozwiak and @iefremov - logged follow up issue brave/brave-browser#13837 and current fix can be uplifted since it seems to have decreased the frequency of the crash.