Bugzilla

This is indeed caused by bug 1878993. The fresh pseudo-main process that runs `nsWinRemoteClient::SendCommandLine` has `/prefetch:1` appended to its command line by the fresh launcher process as a consequence of bug 1878993. `nsWinRemoteClient::SendCommandLine` fetches the command line with `::GetCommandLineW()`, which will still contain `/prefetch:1` since that is the raw command line (we only remove `/prefetch:` prefixes in `wmain` [here](https://searchfox.org/mozilla-central/source/toolkit/xre/nsWindowsWMain.cpp#139)). In the true main process the [`WindowProc`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteServer.cpp#56) from `nsWinRemoteServer.cpp` will retrieve the sent command line and reach `nsCommandLine::Init` which [has special parsing code for Windows](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#364-421) that will convert `/prefetch:1` to `-prefetch 1`. When we then reach [`nsCommandLine::Run`](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#511), `-prefetch` will be ignored but `1` will be interpreted as trying to launch `1` as a URL which expands to `https://0.0.0.1/` (which can be reproduced by launching `firefox.exe 1`).

The safest option seems a backout here to give us the time for a proper rewrite and testing.

This is indeed caused by bug 1878993. The fresh pseudo-main process that runs `nsWinRemoteClient::SendCommandLine` has `/prefetch:1` appended to its command line by the fresh launcher process as a consequence of bug 1878993. `nsWinRemoteClient::SendCommandLine` fetches the command line with `::GetCommandLineW()`, which will still contain `/prefetch:1` since that is the raw command line (we only remove `/prefetch:` prefixes in `wmain` [here](https://searchfox.org/mozilla-central/source/toolkit/xre/nsWindowsWMain.cpp#139)). In the true main process the [`WindowProc`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteServer.cpp#56) from `nsWinRemoteServer.cpp` will retrieve the sent command line and reach `nsCommandLine::Init` which [has special parsing code for Windows](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#364-421) that will convert `/prefetch:1` to `-prefetch 1`. When we then reach [`nsCommandLine::Run`](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#511), `-prefetch` will be ignored but `1` will be interpreted as trying to launch `1` as a URL which expands to `https://0.0.0.1/` (which can be reproduced by launching `firefox.exe 1`).

The safest option seems a backout here to give us the time for proper rewriting and testing.

This is indeed caused by bug 1878993. The fresh pseudo-main process that runs `nsWinRemoteClient::SendCommandLine` has `/prefetch:1` appended to its command line by the fresh launcher process as a consequence of bug 1878993. `nsWinRemoteClient::SendCommandLine` fetches the command line with `::GetCommandLineW()`, which will still contain `/prefetch:1` since that is the raw command line (we only remove `/prefetch:` prefixes in `wmain` [here](https://searchfox.org/mozilla-central/source/toolkit/xre/nsWindowsWMain.cpp#139)). In the true main process the [`WindowProc`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteServer.cpp#56) from `nsWinRemoteServer.cpp` will retrieve the sent command line and reach `nsCommandLine::Init` which [has special parsing code for Windows](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#364-421) that will convert `/prefetch:1` to `-prefetch 1`. When we then reach [`nsCommandLine::Run`](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#511), `-prefetch` will be ignored but `1` will be interpreted as trying to launch `1` as a URL which expands to `https://0.0.0.1/` (which can be reproduced by launching `firefox.exe 1`).

The safest option seems a backout here to give us the time for proper rewriting and testing, especially since we have not seen a significant impact from the patch according to bug 1878993 comment 17.

This is indeed caused by bug 1878993. The fresh pseudo-main process that runs `nsWinRemoteClient::SendCommandLine` has `/prefetch:1` appended to its command line by the fresh launcher process as a consequence of bug 1878993. `nsWinRemoteClient::SendCommandLine` fetches the command line with `::GetCommandLineW()`, which will still contain `/prefetch:1` since that is the raw command line (we only remove `/prefetch:` prefixes in `wmain` [here](https://searchfox.org/mozilla-central/source/toolkit/xre/nsWindowsWMain.cpp#139)). In the true main process the [`WindowProc`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteServer.cpp#56) from `nsWinRemoteServer.cpp` will retrieve the sent command line and reach `nsCommandLine::Init` which [has special parsing code for Windows](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#364-421) that will convert `/prefetch:1` to `-prefetch 1`. When we then reach [`nsCommandLine::Run`](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#511), `-prefetch` will be ignored but `1` will be interpreted as trying to launch `1` as a URL, which expands to `https://0.0.0.1/` (which can be reproduced by launching `firefox.exe 1`).

The safest option seems a backout here to give us the time for proper rewriting and testing, especially since we have not seen a significant impact from the patch according to bug 1878993 comment 17.

This is indeed caused by bug 1878993. The fresh pseudo-main process that runs `nsWinRemoteClient::SendCommandLine` has `/prefetch:1` appended to its command line by the fresh launcher process as a consequence of bug 1878993. `nsWinRemoteClient::SendCommandLine` fetches the command line with `::GetCommandLineW()`, which will still contain `/prefetch:1` since that is the raw command line (we only remove `/prefetch:` prefixes in `wmain` [here](https://searchfox.org/mozilla-central/source/toolkit/xre/nsWindowsWMain.cpp#139)). In the true main process the [`WindowProc`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteServer.cpp#56) from `nsWinRemoteServer.cpp` will retrieve the sent command line and reach `nsCommandLine::Init` which [has special parsing code for Windows](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#364-421) that will convert `/prefetch:1` to `-prefetch 1`. When we then reach [`nsCommandLine::Run`](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#511), `-prefetch` will be ignored but `1` will be interpreted as trying to launch `1` as a URL, which expands to `https://0.0.0.1` (which can be reproduced by launching `firefox.exe 1`).

The safest option seems a backout here to give us the time for proper rewriting and testing, especially since we have not seen a significant impact from the patch according to bug 1878993 comment 17.

This is indeed caused by bug 1878993. The fresh pseudo-main process that runs `nsWinRemoteClient::SendCommandLine` has `/prefetch:1` appended to its command line by the fresh launcher process as a consequence of bug 1878993. [`nsWinRemoteClient::SendCommandLine`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteClient.cpp#17) fetches the command line with `::GetCommandLineW()`, which will still contain `/prefetch:1` since that is the raw command line (we only remove `/prefetch:` prefixes in `wmain` [here](https://searchfox.org/mozilla-central/source/toolkit/xre/nsWindowsWMain.cpp#139)). In the true main process the [`WindowProc`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteServer.cpp#56) from `nsWinRemoteServer.cpp` will retrieve the sent command line and reach `nsCommandLine::Init` which [has special parsing code for Windows](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#364-421) that will convert `/prefetch:1` to `-prefetch 1`. When we then reach [`nsCommandLine::Run`](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#511), `-prefetch` will be ignored but `1` will be interpreted as trying to launch `1` as a URL, which expands to `https://0.0.0.1` (which can be reproduced by launching `firefox.exe 1`).

The safest option seems a backout here to give us the time for proper rewriting and testing, especially since we have not seen a significant impact from the patch according to bug 1878993 comment 17.

This is indeed caused by bug 1878993. Note that to reproduce the bug you need to have a running instance of Firefox already, then the STR from comment 5 should work. The fresh pseudo-main process that runs `nsWinRemoteClient::SendCommandLine` has `/prefetch:1` appended to its command line by the fresh launcher process as a consequence of bug 1878993. [`nsWinRemoteClient::SendCommandLine`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteClient.cpp#17) fetches the command line with `::GetCommandLineW()`, which will still contain `/prefetch:1` since that is the raw command line (we only remove `/prefetch:` prefixes in `wmain` [here](https://searchfox.org/mozilla-central/source/toolkit/xre/nsWindowsWMain.cpp#139)). In the true main process the [`WindowProc`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteServer.cpp#56) from `nsWinRemoteServer.cpp` will retrieve the sent command line and reach `nsCommandLine::Init` which [has special parsing code for Windows](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#364-421) that will convert `/prefetch:1` to `-prefetch 1`. When we then reach [`nsCommandLine::Run`](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#511), `-prefetch` will be ignored but `1` will be interpreted as trying to launch `1` as a URL, which expands to `https://0.0.0.1` (which can be reproduced by launching `firefox.exe 1`).

The safest option seems a backout here to give us the time for proper rewriting and testing, especially since we have not seen a significant impact from the patch according to bug 1878993 comment 17.

This is indeed caused by bug 1878993. Note that to reproduce the bug you need to have a running instance of Firefox already, then the STR from comment 5 work for me. The fresh pseudo-main process that runs `nsWinRemoteClient::SendCommandLine` has `/prefetch:1` appended to its command line by the fresh launcher process as a consequence of bug 1878993. [`nsWinRemoteClient::SendCommandLine`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteClient.cpp#17) fetches the command line with `::GetCommandLineW()`, which will still contain `/prefetch:1` since that is the raw command line (we only remove `/prefetch:` prefixes in `wmain` [here](https://searchfox.org/mozilla-central/source/toolkit/xre/nsWindowsWMain.cpp#139)). In the true main process the [`WindowProc`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteServer.cpp#56) from `nsWinRemoteServer.cpp` will retrieve the sent command line and reach `nsCommandLine::Init` which [has special parsing code for Windows](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#364-421) that will convert `/prefetch:1` to `-prefetch 1`. When we then reach [`nsCommandLine::Run`](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#511), `-prefetch` will be ignored but `1` will be interpreted as trying to launch `1` as a URL, which expands to `https://0.0.0.1` (which can be reproduced by launching `firefox.exe 1`).

The safest option seems a backout here to give us the time for proper rewriting and testing, especially since we have not seen a significant impact from the patch according to bug 1878993 comment 17.

This is indeed caused by bug 1878993. (Edit: Note that to reproduce the bug you need to have a running instance of Firefox already, then the STR from comment 5 work for me.) The fresh pseudo-main process that runs `nsWinRemoteClient::SendCommandLine` has `/prefetch:1` appended to its command line by the fresh launcher process as a consequence of bug 1878993. [`nsWinRemoteClient::SendCommandLine`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteClient.cpp#17) fetches the command line with `::GetCommandLineW()`, which will still contain `/prefetch:1` since that is the raw command line (we only remove `/prefetch:` prefixes in `wmain` [here](https://searchfox.org/mozilla-central/source/toolkit/xre/nsWindowsWMain.cpp#139)). In the true main process the [`WindowProc`](https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsWinRemoteServer.cpp#56) from `nsWinRemoteServer.cpp` will retrieve the sent command line and reach `nsCommandLine::Init` which [has special parsing code for Windows](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#364-421) that will convert `/prefetch:1` to `-prefetch 1`. When we then reach [`nsCommandLine::Run`](https://searchfox.org/mozilla-central/source/toolkit/components/commandlines/nsCommandLine.cpp#511), `-prefetch` will be ignored but `1` will be interpreted as trying to launch `1` as a URL, which expands to `https://0.0.0.1` (which can be reproduced by launching `firefox.exe 1`).

The safest option seems a backout here to give us the time for proper rewriting and testing, especially since we have not seen a significant impact from the patch according to bug 1878993 comment 17.