1746377 - Firefox can't access internet in VMWare Fusion after network restart

Status: NEW

(Core :: Networking, defect, P2)

Description

[Nenad]

Attachment: Screenshot 2021-12-16_12-53-23-016.png

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93 Safari/537.36

Steps to reproduce:

I resume my VMWare session from suspended.

Actual results:

Firefox can no longer access internet. Also Thunderbird. Until they are restarted. But then I have to reload all my tabs and place out my windows where I want them. This is really annoying and takes a lot of extra time.

All other applications work as they should. E.g. I am writing this in Chromium since Firefox is not able to do its job.

This does not happen every single time, but most of the times so it should be fairly easy to reproduce.

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0

Running on OpenSUSE 15.3 (Linux nacvirtopensuse 5.3.18-59.37-preempt #1 SMP PREEMPT Mon Nov 22 12:29:04 UTC 2021 (d10168e) x86_64 GNU/Linux)
on VMWare Fusion Professional Version 12.1.2 (17964953)
on MacOS Catalina 10.15.7 (19H1519)

Expected results:

Firefox and Thunderbird should be able to continue working after the VM is resumed like all other applications.

Comment 1

[Nenad]

This is not new defect in the current version. This has been happening for years. I just never got around to file a bug report. Hoping that it would go away. But as computer performance keeps increasing and I have more and more tabs and windows up the annoyance to have to restart just because I resume my VM just gets bigger and bigger. Especially since NO other apps have this problem. What is Mozilla doing with the network stack that is not compatible?

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Valentin Gosu [:valentin] (he/him)]

This is caused by the platform DNS APIs sometimes stop working after a network change.
Sometimes it recovers, such as in bug 1713798, but sometimes not. I haven't managed to figure out why. Possibly a bug within NSPR.
I'll try to reproduce with a VM.