Fix: Improve webview rendering robustness and error handling

[hannesrudolph]

Another jules experiment
This change addresses potential grey/blank screen or crashing issues in the webview by:

1. Adding an ErrorBoundary: I introduced an ErrorBoundary component at the root of webview-ui/src/App.tsx. This component catches JavaScript rendering errors in its children, displaying a user-friendly fallback UI instead of a blank or broken screen. It also logs the error to the console for easier debugging.

2. Implementing Loading/Timeout Logic: I modified webview-ui/src/App.tsx to:

   • Display a "Loading..." message while the initial extension state (didHydrateState) is being processed.
   • Implement a 10-second timeout. If state hydration doesn't complete within this period, an error message is shown, guiding you to try reloading or checking for updates. This provides better feedback than a persistent blank screen.

3. Adding Unit Tests:

   • I created tests for the ErrorBoundary to ensure it correctly catches errors and renders the fallback UI or child components as expected.
   • I created tests for the App.tsx loading and timeout logic to verify that loading indicators and error messages are displayed appropriately under different hydration scenarios.

These changes aim to make the webview more resilient to rendering errors and provide better feedback to you during initialization, improving the overall user experience and aiding in diagnosing future issues.

Related GitHub Issue

Closes: #

Description

Test Procedure

Type of Change

• 🐛 Bug Fix: Non-breaking change that fixes an issue.
• ✨ New Feature: Non-breaking change that adds functionality.
• 💥 Breaking Change: Fix or feature that would cause existing functionality to not work as expected.
• ♻️ Refactor: Code change that neither fixes a bug nor adds a feature.
• 💅 Style: Changes that do not affect the meaning of the code (white-space, formatting, etc.).
• 📚 Documentation: Updates to documentation files.
• ⚙️ Build/CI: Changes to the build process or CI configuration.
• 🧹 Chore: Other changes that don't modify src or test files.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Code Quality:
  • My code adheres to the project's style guidelines.
  • There are no new linting errors or warnings (npm run lint).
  • All debug code (e.g., console.log) has been removed.
• Testing:
  • New and/or updated tests have been added to cover my changes.
  • All tests pass locally (npm test).
  • The application builds successfully with my changes.
• Branch Hygiene: My branch is up-to-date (rebased) with the main branch.
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Changeset: A changeset has been created using npm run changeset if this PR includes user-facing changes or dependency updates.
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

Documentation Updates

Additional Notes

Get in Touch

[samhvw8]

@hannesrudolph this's cool, can we add telemetry to this section too ?

[hannesrudolph]

@hannesrudolph this's cool, can we add telemetry to this section too ?

This is just an experiment with jules the code agent.