SLBr Technical Overview

SLBr displays internationalized domain names (IDNs) in a readable Unicode format instead of an encoded Punycode representation.

This improves readability for users, allowing domains that contain Unicode characters, symbols, or emojis to appear as intended, rather than as encoded "xn--" strings that are difficult for users to interpret.

However, rendering Unicode domains directly introduced a significant security concern, that is homograph attacks.

Homograph attacks exploit visually similar characters to create deceptive domain names, such as replacing Latin characters with Cyrillic or Greek characters.

Examples include:

• vvikipedia.com
• аррӏе.com

To address this risk, SLBr implemented a homograph detection and highlighting system within the omnibox.

When potentially confusable or suspicious characters are detected, those characters are highlighted in orange, making them visually distinct from other characters.

This approach provides several benefits:

• Internationalized domains remain readable.
• Suspicious domains become visually noticeable.
• Users are not forced to interpret encoded Punycode URLs.

The initial implementation rendered each character of the domain as an individual text run.

This was inefficient and introduced unnecessary rendering overhead, especially during frequent omnibox updates.

SLBr now uses a buffered rendering approach:

• Characters are grouped into segments.
• Each segment is rendered as a single text run.
• Suspicious and normal characters are batched separately.

This significantly reduced the number of UI elements created per update, improving rendering performance.

SLBr supports multiple web engines through a unified abstraction layer.

Rather than binding SLBr directly to a specific web engine, SLBr treats each engine as an implementation behind a shared interface.

This allows the browser core to remain engine-agnostic while still supporting different web engines.

Earlier versions of SLBr implemented multi-engine support through conditional logic.

Multiple web engines such as CefSharp (Chromium), WebView2 (Microsoft Edge), and WebBrowser (Internet Explorer) were used directly throughout the codebase without a shared interface.

This approach resulted in several issues:

• Extensive engine-specific conditionals scattered across the codebase.
• Tight coupling between browser logic and individual engines.
• Poor maintainability and limited extensibility.
• Increasing difficulty adding new features or engines while maintaining parity.

As development continued, the code quickly became a complex and unmanageable set of engine-specific cases.

Due to these issues, the multi-engine feature was effectively shelved for a period of time, as maintaining feature parity and stability across engines became impractical without a fundamental redesign.

In addition, engine features became highly inconsistent. The conditional-based implementation often resulted in features being developed primarily for a single engine, while other engines received incomplete or no support.

To resolve these issues, SLBr now uses an adapter-based architecture to support multiple web engines.

Each web engine is wrapped by an adapter that translates engine-specific APIs into a shared interface.

The browser core interacts with the engines through a single interface, remaining mostly unaware of which engine is currently in use.

This architecture provides several benefits:

• Engine-specific behavior is fully isolated.
• New engines can be added without extensively modifying existing browser logic.
• Conditional engine checks are largely eliminated.
• Overall codebase remains clean and maintainable.
• Feature parity is significantly improved.

As a result, SLBr can more easily support additional engines in the future, such as GeckoFX, Ultralight, or other web engine implementations.

The new architecture also enabled proper handling of custom protocol schemes such as gemini://, gopher://, and slbr:// across different web engines.

Under the previous conditional-based implementation, adding protocol support across multiple engines was impractical due to deeply intertwined engine-specific logic.

With the new architecture, protocol handling is centralized and applied consistently, making it significantly easier to extend and maintain.

Despite the architectural improvements, not all web engines provide the same level of functionality.

Some limitations include:

• Extension support is not fully standardized.
• Certain features, such as downloads and popups, behave inconsistently.
• Legacy web engines like Internet Explorer lack many modern web capabilities.

These constraints are inherent to the underlying engines themselves rather than the architecture.

In SLBr, specific internal browser pages relies on C# and XAML, rather than HTML and Javascript.

Relying on HTML and JavaScript posed technical challenges in a multi-engine architecture, as behavior varied between web engines.

In early versions of SLBr, the Settings page was implemented as a special standalone tab, rather than a navigable page.

Users could not access it via a URL such as slbr://setting, and the tab system required custom handling to support this exception.

This approach resulted in several issues:

• Internal pages were not navigable.
• Further complicated tab system due to special-case handling.
• Inconsistent behavior between web engines.

As a result, a new approach was introduced to integrate internal pages with the browser's navigation model.

SLBr now uses an overlay-based page system, where internal pages are implemented as User Controls rendered on top of the web view.

From a user's perspective, these pages behave like normal navigable URLs, while internally they are rendered natively using WPF rather than HTML.

This approach provides several advantages:

• Internal pages are fully navigable.
• No special tab logic required.
• Internal pages can be developed using C# and XAML.
• Behavior remains consistent across all web engines.
• Avoids exposing privileged browser information to JavaScript.

Because the overlay is engine-agnostic, it integrates cleanly with the existing multi-engine abstraction layer and avoids relying on engine-specific HTML and JavaScript capabilities.

Following the success of the Settings page, other internal pages such as History were also migrated from HTML/JavaScript implementations to native WPF overlays.

This transition provides several benefits:

• Simplified development and improved internal integration.
• Browser information can be accessed directly without polling or scripting bridges.
• UI updates react immediately to changes.
• Instant loading for instant pages.

This approach results in a cleaner, more maintainable design, while still presenting internal pages as part of a smooth browsing experience.

Early versions of SLBr relied directly on the built-in spellcheck functionality provided by the underlying CefSharp & WebView2 engines.

This approach was simple, providing real-time spellchecking without additional infrastructure.

However, a later Chromium update introduced changes that rendered the built-in spellcheck unreliable.

As a result, spellchecking functionality became unavailable for an extended period of time.

To restore spellchecking support, SLBr transitioned to an engine-agnostic cloud-based solution powered by LanguageTool.

Rather than performing continuous, real-time spellchecking, SLBr adopted an on-demand request model.

Spellcheck requests are triggered only when text is selected and the context menu is opened.

This design introduced several benefits:

• Lower request frequency compared to traditional real-time spellcheckers.
• Significantly reduced bandwidth usage.
• Reduced risk of sensitive data leakage since text is not transmitted while typing.
• Consistent behavior across all web engines.

Despite these advantages, the cloud-based approach had notable drawbacks:

• Spellchecking required an active internet connection.
• Sending requests introduced significant privacy concerns.
• Network latency affected context menu responsiveness.
• Total reliance on an external service.
• Increased bandwidth usage.

To address these issues, SLBr added a local spellchecking provider based on WPF's built-in spellchecker.

This provider contains several advantages:

• Operates entirely on the client side.
• Near-instant spellcheck results.
• Remains functional without an active internet connection.
• Zero network usage.
• Improved responsiveness when opening context menus.

While this option does not offer the same language depth as cloud-based solutions, it significantly improves performance and reliability for common use cases.

During further development, Microsoft Edge's cloud-based spellchecker was discovered and integrated as an additional provider.

Earlier versions of SLBr used a single global timer to manage tab unloading.

Under this system, all inactive tabs were evaluated and unloaded at the same time once the timer elapsed.

While simple, this approach introduced several usability issues:

• The system did not account for tab usage.
• Recently visited tabs could be unloaded shortly after switching away.

This resulted in unnecessary reloads and a disruptive browsing experience.

To address these issues, SLBr now uses a per-tab unload scheduling architecture.

Each tab tracks its own last active time and is assigned an independent expiry window.

This ensures that tabs that were recently accessed are preserved and remain available for a longer duration, while older inactive tabs are unloaded progressively.

In addition to per-tab tracking, adaptive timer scheduling was introduced to the system.

Instead of using a fixed interval, the system dynamically adjusts its scheduling based on the nearest tab expiry time.

This is implemented using a timer that recalibrates itself to trigger precisely when the next tab is due for unloading.

This approach provides:

• More precise unload timing.
• Reduced unnecessary timer wake-ups.
• Improved overall efficiency.