SLBr Known Issues & Limitations

SLBr is built on top of embedded web engines, and is therefore inherently constrained by the APIs and behaviors exposed by those engines.

This means that SLBr does not have access to low-level Chromium internals and must rely entirely on the public interfaces provided by each embedded browser library.

As a result, certain browser behaviors cannot be fully intercepted and modified.

Furthermore, any breakages in upstream features (such as spellcheck) directly affect SLBr.

Here are the following engine-specific limitations:

• WebView2 (Microsoft Edge)
  • Inability to intercept or modify all network requests, preventing full user agent branding and request-level modification.
  • Limited control over new window creation, making it difficult to reliably determine whether a new tab should open in the foreground or background.
  • Missing APIs for features such as image upload popups and font customization.
• Trident (Internet Explorer)
  • No access to Internet Explorer's developer tools.
  • No reliable way to modify the native context menu.

Because SLBr embeds these engines directly, any crash or instability within an engine may result in a crash of the browser itself.

SLBr's UI is built using WPF, which does not natively support full-color emoji rendering without workarounds.

As a result, colored emojis are not supported only in the WPF UI.

Web content rendered inside the web engines remain unaffected and displays emojis correctly.

This is a long-standing limitation of WPF and is outside SLBr's control.

SLBr's multi-engine architecture significantly complicates extension support.

Each web engine implements extension APIs differently, and none of the embedding libraries prioritize full extension APIs.

This has several disadvantages:

• Extensions cannot be implemented consistently across all engines.
• Extension capabilities are limited compared to single-engine browsers.

Due to these constraints, SLBr currently only offers minimal extension support.

SLBr relies heavily on WPF and Windows-specific web engines such as WebView2, CefSharp, and Trident.

As a result, SLBr cannot be easily ported to cross-platform frameworks such as MAUI or Avalonia.

Equivalent browser controls on cross-platform frameworks are often significantly more limited and maintaining the same feature set across platforms would not be feasible.

While a cross-platform implementation may be theoretically possible in a separate project, SLBr's current architecture is inherently Windows-focused.