Fix render-blocking asset deadlock on Windows local resource loading

[GoCoder7]

Hi everyone,

1. Problem Statement

On Windows, applications loading local stylesheets or assets via compile-time absolute paths (e.g. asset!("browser.css") resolving to D:\...\browser.css) experience a permanent render-blocking deadlock, leaving the window client area solid white (#FFFFFF).

Failure Chain:

1. URL Scheme Misparsing: In packages/blitz-dom/src/document.rs::resolve_url(raw), Windows absolute paths starting with a drive letter (e.g. D:\...) are passed to url::Url::parse(). The URL parser interprets the drive letter "D" as a custom URL scheme (url.scheme() == "d").
2. Asset Resolver Bypass: Because the scheme is "d" rather than "dioxus", dioxus-native delegates the request to blitz_net::Provider.
3. Handler Dropped on Error: blitz-net attempts to fetch scheme "d", encounters an unsupported scheme error, logs a warning, and drops the ResourceHandler.
4. Permanent DOM Deadlock: ResourceHandler does not implement Drop. When dropped without calling respond(), no ResourceLoadResponse is sent to BaseDocument. Consequently, pending_critical_resources.remove(&request_id) is never invoked, leaving has_pending_critical_resources() permanently true.
5. Drawing Bypassed: Both blitz-dom::resolve and blitz-shell::redraw check has_pending_critical_resources(). Because the count never clears, the layout and paint passes are aborted on every frame (render_skipped=true). The window displays only the clear color (#FFFFFF).

---

2. Direct Empirical Proof (Two-Case Comparison)

To confirm that this asset deadlock is an independent root cause and not an artifact of GPU presentation, I conducted a controlled dual-run verification on Windows hardware with the GPU backend held strictly constant (DirectX 12 enabled via patched wgpu_context):

• Case A (Original Blitz + DX12 Backend):
  • Reverted the Blitz Seam 1 fixes while keeping DX12 active.
  • Runtime probes recorded: pending_count=2, zero calls to load_resource, early_return=true (has_pending_critical_resources), and render_skipped=true.
  • Visual result: The window remained permanently blank white (#FFFFFF) despite healthy DX12 swapchain initialization.
• Case B (Fixed Blitz + DX12 Backend):
  • Applied the Blitz Seam 1 fixes.
  • Runtime probes recorded: valid file:/// URLs, successful load_resource completions, pending_critical_resources clearing from 2 -> 0, and render_skipped=false.
  • Visual result: The entire browser UI (tabs, toolbar, navigation, Blitz logo, search input) rendered crisply.

This confirms that even with a healthy DX12 graphics backend, original Blitz independently blocks rendering on Windows.

---

3. Why This Belongs in Blitz

This issue belongs entirely in dioxuslabs/blitz:

• The URL resolution error occurs in blitz-dom::resolve_url.
• The resource tracking deadlock occurs in blitz-dom's pending_critical_resources map and ResourceHandler lifecycle.
• The file:// path extraction occurs in blitz-net.

It is completely separate from the GPU backend selection policy, which is tracked upstream in dioxuslabs/anyrender (Issue DioxusLabs/anyrender#99 / PR DioxusLabs/anyrender#100).

---

4. Desired Behavior

1. Windows Drive Path Resolution: BaseDocument::resolve_url should detect Windows absolute drive paths (e.g. ^[a-zA-Z]:[\\/]) and normalize them to valid file:/// URLs via url::Url::from_file_path.
2. ResourceHandler Drop-Safety: ResourceHandler must implement Drop. If dropped before respond() is called, it should automatically emit a failure ResourceLoadResponse so that pending_critical_resources is guaranteed to clear.
3. Windows file:// Normalization in blitz-net: Provider should use request.url.to_file_path() instead of request.url.path() to correctly support Windows drive letters and UNC paths.

---

Thanks!