tw93/Pake · info

about:blank must be a valid URL

Error message

about:blank must be a valid URL

What it means

This is a Rust `.expect(...)` panic on `Url::parse("about:blank")` in the macOS auth-popup path of `build_window` (src-tauri/src/app/window.rs:401). The `url` crate's parser rejects strings that are not valid RFC 3986 URLs; the `.expect` converts a failed parse into a hard panic at window creation. In practice `about:blank` is a valid URL and always parses, so this panic is a defensive assertion, not a condition users can normally reach.

Source

Thrown at src-tauri/src/app/window.rs:401

    // On macOS both HTTP Basic auth and certificate bypass use the same
    // navigation-delegate proxy. Start on a neutral page so the proxy is in
    // place before the target can issue its first authentication challenge.
    #[cfg(target_os = "macos")]
    let auth_target = if label == "pake"
        && window_config.url_type == "web"
        && (config.basic_auth || window_config.ignore_certificate_errors)
    {
        Url::parse(&window_config.url).ok()
    } else {
        None
    };

    // The delegate must be installed before the first TLS challenge. Start on
    // a neutral page, then navigate from the with_webview callback below.
    #[cfg(target_os = "macos")]
    let url = if auth_target.is_some() {
        WebviewUrl::CustomProtocol(
            Url::parse("about:blank").expect("about:blank must be a valid URL"),
        )
    } else {
        url
    };

    let user_agent = config.user_agent.get();

    let config_script = format!(
        "window.pakeConfig = {}",
        serde_json::to_string(&window_config).unwrap_or_else(|_| "{}".to_string())
    );

    // Platform-specific title: macOS prefers empty, others fallback to product name
    let effective_title = window_config.title.as_deref().unwrap_or_else(|| {
        if cfg!(target_os = "macos") {
            ""
        } else {
            tauri_config.product_name.as_deref().unwrap_or("")

View on GitHub (pinned to 777dd552ad)

Solutions

1. Keep the literal as `about:blank` — it always parses; if you hit this panic, diff the string against the original literal in window.rs:401
2. Replace `.expect(...)` with graceful error handling: `Url::parse(s).map_err(|e| ...)` and fall back to the plain `url` branch instead of starting on the neutral page
3. If parsing a dynamic string, validate it before calling `Url::parse`, e.g. require a scheme: `if !s.contains("://") && s != "about:blank" { prepend "https://" }`
4. Pin/upgrade the `url` crate and re-run `cargo build` to rule out a version-specific parser regression

Example fix

// before
WebviewUrl::CustomProtocol(
    Url::parse("about:blank").expect("about:blank must be a valid URL"),
)
// after
let neutral = Url::parse("about:blank")
    .map_err(|e| anyhow::anyhow!("neutral page URL invalid: {e}"))?;
WebviewUrl::CustomProtocol(neutral)

fn is_parseable_url(s: &str) -> bool {
    url::Url::parse(s).is_ok()
}
// call before using the value as a WebviewUrl
assert!(is_parseable_url("about:blank"));

fn valid_url(s: &str) -> Option<url::Url> {
    url::Url::parse(s).ok()
}

let parsed = url::Url::parse(input).map_err(|e| format!("invalid URL '{input}': {e}"))?; // propagate instead of expect

When it happens

Trigger: Only reachable when compiling on `target_os = "macos"` with `auth_target.is_some()` (a macOS Basic Auth / certificate-error flow) AND the literal `"about:blank"` string being changed to something the `url` crate cannot parse. A plain `Url::parse("about:blank")` in user code panics only if the string is malformed (bad scheme, invalid percent-encoding, missing scheme, etc.).

Common situations: Developers hit this pattern when (1) refactoring the hardcoded `about:blank` literal into a config value or constant and mistyping it, (2) copying the parse-expect idiom with user-supplied URL strings that may lack a scheme, or (3) using an older `url` crate version whose parser is stricter about some scheme forms. End users of the packaged app essentially never see it.

Related errors

• web URLs must have a host

AI-assisted analysis of tw93/Pake@777dd552ad (2026-09-05). Data as JSON: /api/errors/154b2a849e5ce685. Report an issue: GitHub.