[vector_graphics] Catch any throwable in useHtmlRenderObject() and cache HTML fallback - #13545

In Flutter Web under the CanvasKit and WebAssembly renderers, vector graphics determine whether to use native raster rendering (_RawVectorGraphicWidget) or an HTML compatibility renderer (_RawWebVectorGraphicWidget) by calling useHtmlRenderObject(), which probes runtime support by recording a 1x1 ui.Picture and invoking picture.toImageSync(1, 1).

Previously, useHtmlRenderObject() caught only a narrow allow-list of exception types (UnsupportedError, StateError, and NoSuchMethodError). When WebGL surface creation or OffscreenCanvas initialization fails mid-session, CanvasKit and browser environments can throw unhandled throwables such as bare JavaScript strings ('Canvas with id [object OffscreenCanvas] was not found'), foreign JS errors, or null. Because these were unhandled, VectorGraphic widgets crashed, and because useHtmlRenderObject() is evaluated in a static field initializer, subsequent widget builds re-evaluated the uninitialized field and re-threw continuously. Furthermore, _cachedUseHtmlRenderObject remained null on failure, preventing the HTML fallback from ever being recorded.

This PR updates useHtmlRenderObject() to catch any throwable using a bare catch (_) block, sets _cachedUseHtmlRenderObject = true on any failure, ensures ui.Picture and ui.Image resources are always disposed in finally, and adds unit tests covering five distinct failure modes, success path caching, and reset lifecycle transitions.

Fixes flutter/flutter#189451

Behavioral Changes

• Before: When picture.toImageSync(1, 1) threw non-Dart errors (such as bare JavaScript strings or foreign JS errors during WebGL/canvas failures), the throwable escaped unhandled from useHtmlRenderObject(), crashing VectorGraphic widget build passes and re-throwing repeatedly without caching a fallback.
• After: Any throwable thrown during toImageSync(1, 1) is caught, causing useHtmlRenderObject() to return true (selecting the HTML compatibility render object) and permanently cache _cachedUseHtmlRenderObject = true so subsequent widget builds reuse the fallback without re-triggering the failing probe.

Where to focus

• Key Architectural Decisions:
  • Replaced specific on exception clauses with an open catch (_) block in render_object_selection.dart. On web compilation targets (dart2js and dart2wasm), host JavaScript runtimes can throw arbitrary values (including bare strings, JS objects, or null); Dart null safety excludes null from Object, making catch (_) the only clause that intercepts every possible thrown entity.
  • Latching _cachedUseHtmlRenderObject = true on any caught throwable prevents repeat probe execution and CPU thrashing during environmental rendering failures.
• Non-Obvious Logic:
  • Checking if (_cachedUseHtmlRenderObject != null) prior to if (!kIsWeb && debugToImageSyncOverride == null) allows non-web test environments (such as the Dart VM) to hermetically simulate both probe success and probe failure via debugToImageSyncOverride without allocating native browser surfaces.
• Primary Review Files:
  • packages/vector_graphics/lib/src/render_object_selection.dart: Core fallback catch and caching logic.
  • packages/vector_graphics/test/render_object_selection_test.dart: Hermetic unit test suite covering string, error, exception, null, and foreign object throws, plus caching and reset semantics.

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.