1892612 - Firefox opens tab with IP address 0.0.0.1

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect, P1)

Description

[Sören Hentzschel]

Attachment: screenshot of the opened tab

In the last 6 days, there have been reports from 13 different users in the German-speaking Firefox support forum, all reporting the same problem. Rarely has there been a problem with Firefox that has brought so many new users to our support forum, so the number of affected users may be much higher. However, it is unclear whether there is a cause in Firefox at all or whether Mozilla's solution may ultimately be a support article or something similar.

The reported issue is that Firefox always opens a tab with the address https://0.0.0.1 by itself. This can happen when following links, but also when opening new windows. All users report the first occurrence since Firefox 125.0.1, although it cannot be ruled out that this is only a coincidental temporal connection to the release of Firefox 125. So far, only one user has been able to run mozregression and all builds have been fine.

One user reports that the problem does not occur on all websites. He was not able to reproduce on DeepL or ChatGPT, but on google.de, gmail.com and wikipedia.org.

One user has observed that whenever this happens, an unknown icon appears in the Windows taskbar at the same time, which disappears immediately.

An ADWcleaner scan from some users did show Malware and removing it solved it for some users.

What all users have in common is that they use Windows.

The following questions remain:

• Why is the problem suddenly occurring for so many users
• Why is only Firefox affected?

Let me know if there is specific information you would like me to request.

Comment 1

[Sören Hentzschel]

Attachment: screenshot of the unknown icon in the Windows task bar

Comment 2

[Donal Meehan [:dmeehan]]

Thanks Sören, for the bug report.
Will share to see if we can

In the meantime, are any of the reporters willing to try mozregression? This would help to narrow down what introduced this?
https://mozilla.github.io/mozregression/quickstart.html

Comment 3

[Donal Meehan [:dmeehan]]

Also, if they could try in Troubleshoot Mode to rule out a plugin issue?
https://support.mozilla.org/en-US/kb/diagnose-firefox-issues-using-troubleshoot-mode

There are some unconfirmed reports that it could be caused by uBlock Origin
https://www.reddit.com/r/firefox/comments/1c87ggs/ranndom_tab_opening/

Similar issue:
https://github.com/microsoft/PowerToys/issues/15288#issuecomment-2066277593

Comment 4

[Sören Hentzschel]

• Neither safe mode nor a new profile solved the issue.
• With mozregression all builds were good.
• Not every affected user uses uBlock Origin.
• In the meantime, we got two more reports. Both were able to solve it after using ADWcleaner.
• One user said that every time a tab opened with 0.0.0.1, the following was logged in the console: unrecognized command line flag -safe-mode BrowserContentHandler.sys.mjs:1472:17

The registry thing from the GitHub link looks interesting. This would probably explain why only Firefox is affected, why mozregression builds are not affected, why a new profile doesn't help, and also the warning about an unrecognized command line flag makes sense as the registry entry uses a command line flag for Firefox. I asked if any of the users can confirm such a registry entry.

Comment 5

[kanapa1]

I have also been experiencing this issue since I updated Firefox to version 125, and I'm not any of those "13 different users in the German-speaking Firefox support forum". However, in my case, this issue is by no means intermittent and is easily reproducible on both Windows 11 23H2 (build 22631) and Windows 10 22H2 (build 19045).

Steps to reproduce:

1. Run Firefox at least version 125 stable in any way, it doesn't matter.
2. Navigate to the Firefox installation directory and execute the following command in a terminal: firefox.exe --foo (basically, pass any argument to the Firefox executable, it can be valid or not, the result is the same anyway).
3. See what is described in the "Current behavior" section.

Current behavior:

A new tab in the current Firefox window or a completely new window is opened with the URL https://0.0.0.1/ (depending on the browser.link.open_newwindow pref value).

Previous behavior:

A new Firefox window without any special tab was opened.

Regression range:

Mozregression points to bug 1878993 as the culprit. Here's the relevant pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ac25a602f99ed767c0e3dce93379237522689104&tochange=98eadcb9210580189dd1cb9eb2cad1362b0c2835

Comment 6

[Gian-Carlo Pascutto [:gcp]]

Going to mark this S1 due to likely high amount of users affected and a likely dot release driver.

Now the question is still why this wasn't seen in Nightly or Beta...

Comment 7

[Francesco Lodolo [:flod]]

(In reply to kanapa1 from comment #5)

2. Navigate to the Firefox installation directory and execute the following command in a terminal: firefox.exe --foo (basically, pass any argument to the Firefox executable, it can be valid or not, the result is the same anyway).

Thanks for going the extra mile and finding a way to reproduce. Can reproduce on Win10 Pro 22H2 with 125.0.2, while 124 was working normally.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1878993

:rkraesig, since you are the author of the regressor, bug 1878993, could you take a look?

For more information, please visit BugBot documentation.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

[Tracking Requested - why for this release]:

Comment 10

[Yannis Juglaret [:yannis]]

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 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). In the true main process the WindowProc from nsWinRemoteServer.cpp will retrieve the sent command line and reach nsCommandLine::Init which has special parsing code for Windows that will convert /prefetch:1 to -prefetch 1. When we then reach nsCommandLine::Run, -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.

Comment 11

[Gian-Carlo Pascutto [:gcp]]

The relation to nsWinRemoteClient gives a hint why this wasn't reported during testing: to hit this bug you have to be already running Firefox and then try to launch it again. So these people have "something" on their system that is (potentially quietly) launching Firefox, and that then fulfills the prerequisite to trigger this bug.

Of course you'd hit this if you intentionally start Firefox before, but from the initial reports - suggesting some people fixed it by finding malware and running ADWcleaner or similar tools - there may be some relation to third party software and not all users are intentionally launching the browser twice. (Or it may be sample bias and people scanned their systems because we behaved weirdly :-/)

Comment 12

[Sören Hentzschel]

Or it may be sample bias and people scanned their systems because we behaved weirdly :-/

We (in Firefox support) have asked the affected users for a scan with ADWcleaner, because the opening of https://0.0.0.1 looked suspicious from our point of view and could indicate (incorrectly functioning) adware. Unfortunately, we know from experience that many users download software via dubious third-party portals that bundle the actual software with other things if they are not careful and simply use the largest download button. So yes, for the affected users, the "weird behavior" of Firefox was (via the detour of our support forum) the reason for a scan. From that point of view, the bug may have been a good thing, at least for those users who scanned their system. 😉

Comment 13

[Gian-Carlo Pascutto [:gcp]]

My concern was that normal usage like clicking a link in another application (like email) would produce this bug if Firefox is already running (either intentionally or quietly). But from testing I don't manage to reproduce it that way, so you likely do need to explicitly try to launch Firefox twice to trigger this. That makes it annoying, but perhaps not as urgent as an S1.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox125 (release), tracked for firefox126 (beta) and tracked for firefox127 (nightly). However, the bug still isn't assigned.

:gcp, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 15

[Gian-Carlo Pascutto [:gcp]]

Going to assign to Ray, Yannis has the backout ready in the original bug.

Comment 16

[Nika Layzell [:nika] (ni? for response)]

It appears that we are failing to strip the preloading arguments in a couple of places where instead of inspecting the passed in argc and argv we directly fetch the initial command line with ::GetCommandLineW. The main case which is likely causing the problem here is nsWinRemoteClient::SendCommandLine, where we use ::GetCommandLineW() to get the command line to send to existing Firefox processes, rather than sending the stripped one, but we also do this in nsUpdateProcessor::AttemptAutomaticApplicationRestartWithLaunchArgs and in chromium's CommandLine implementation.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Added to the 125.0.1 & 125.0.2 relnotes as a known issue:

When attempting to launch Firefox while it is already running, an extra blank tab with an address of https://0.0.0.1 may sometimes appear. The cause of this has been identified and will be resolved in an upcoming release.

Comment 18

[Donal Meehan [:dmeehan]]

Setting Fx126 and Fx127 as disabled
The regressor Bug 1878993 was backed out of central and beta.

Comment 19

[Ray Kraesig [:rkraesig]]

Per discussion on the original bug, I'm going to call this RESOLVED by the backout.

If we're cutting a 125.0.3 release, this should probably be uplifted to release as well, though. Are there plans for one?

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Yes

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Added to the 125.0.3 relnotes.

Fixed an extra blank tab with an address of https://0.0.0.1 sometimes appearing when attempting to launch Firefox when it is already running