WSL runner should check DISPLAY env var before refusing to open browser (WSLg support)

[0xBigBoss]

Description

The WSL runner currently refuses to open browsers unconditionally, but this is outdated given modern WSLg (WSL GUI) support which provides native GUI capabilities with DISPLAY environment variable automatically configured.

Current Behavior

The WSL runner (wsl.mjs) always shows this warning and refuses to open browsers:

WARN  Cannot open browser when using WSL. Load ".output/chrome-mv3-dev" as an unpacked extension manually

This happens even when DISPLAY is set and GUI applications work perfectly.

Expected Behavior

When DISPLAY environment variable is set (indicating WSLg or X11 forwarding), WXT should attempt to open the browser normally instead of refusing.

Environment

• OS: WSL2 with WSLg on Windows 11
• DISPLAY: :10.0 (automatically set by WSLg)
• WXT Version: 0.20.11
• Browser: Google Chrome in WSL2

Reproduction

1. Run WXT in WSL2 with WSLg enabled (Windows 11 default)
2. Run wxt or wxt build
3. Browser fails to open despite DISPLAY being set and GUI support working

Manual Workaround

Browser opens successfully when launched manually with DISPLAY set:

DISPLAY=:10.0 /usr/bin/google-chrome --load-extension=.output/chrome-mv3-dev

Proposed Solution

Update the WSL runner to check for DISPLAY before refusing:

export function createWslRunner() {
  return {
    async openBrowser() {
      // Check if DISPLAY is set (WSLg/X11 support)
      if (!process.env.DISPLAY) {
        wxt.logger.warn(
          \`Cannot open browser when using WSL without GUI support. Load "\${relative(
            process.cwd(),
            wxt.config.outDir
          )}" as an unpacked extension manually\`
        );
        return;
      }
      
      // DISPLAY is set, delegate to default browser runner
      // (let the normal browser opening logic handle it)
    },
    async closeBrowser() {
    }
  };
}

Related Issues

• WSL Support #55 - Original WSL support issue that disabled browser opening entirely
• This was appropriate at the time, but WSLg (released 2021) changes the situation

Impact

This affects all WSL2 users on Windows 11+ who have WSLg enabled by default. The warning is misleading and forces manual browser loading despite GUI support being fully functional.

[infectiousstupidity]

This would be a very welcome change.

[Seismix]

Yes please!

[aklinker1]

Sounds good to me, your example code change looks good, one question. Do you have to check that process.env.DISPLAY === ':10.0' or just check if it's set?

If someone wants to open a PR, feel free to. I don't have windows so I'll need someone else to make this change.

[Seismix]

Sounds good to me, your example code change looks good, one question. Do you have to check that process.env.DISPLAY === ':10.0' or just check if it's set?

If someone wants to open a PR, feel free to. I don't have windows so I'll need someone else to make this change.

Just a note, for my WSL installation DISPLAY is set to :0, which is also the wslg default as far as I can tell: https://github.com/microsoft/wslg/blob/b836effa32844bc32bc858e8dd1c5360791171a5/WSLGd/main.cpp#L235

So maybe just detecting if it is set is a better approach. I'm not sure about all the possible values.

I will take a look at this, it's going to be my first attempted PR though.

[2-fly-4-ai]

Has this been implemented? Still getting the same issues in wsl.

[PatrykKuniczak]

Seems somwbody want to open PR fo this, stay tuned :)

Has this been implemented? Still getting the same issues in wsl.

[Seismix]

I had a first draft ready around Christmas but didn't get around to publish then.

I am ironing out the last kinks, opening the PR soon.

Edit: It's up, please test it!