1640212 - Missing elements of a web page until page reload

Status: RESOLVED INCOMPLETE

(Core :: Networking: Cache, defect, P2)

Description

[mth.provencal]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

Go to facebook, youtube, gmail, reddit, duckduckgo or to an other random internet page.

Actual results:

Firefox, with more and more web pages and more and more often, can't manage to load certain elements (images, part of the page, css style, fonts, etc...) on the first try. I have to reload the page once or even twice or three times to display the page normally.

Expected results:

Normal page loading the first time.

Comment 1

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

I am not able to replicate the issue. I tried on mac OS 10.14, windows 10 pro and ubuntu 18.04.3 LTS , on the following versions

Release 76.0 (64-bit)
Beta 77.0b8 (64-bit)
Firefox Nightly 78.0a1 (2020-05-28) (64-bit)

Please test if the issue occurs to you in safe mode (add-ons disabled). Here is a link that can help you do that:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

If the issue persists, also test it using a fresh profile, you can find the steps to do that below:
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Also, try this on the latest version of nightly. You can download it from here: https://nightly.mozilla.org/

Could you submit a video/picture?

Best,

Clara

Comment 2

[mth.provencal]

The first two pages that I load in safe mode

Twitch (because having to press 10 or 15 times -- without exaggeration -- to be able to display a page without a module error is frustrating)

Comment 3

[mth.provencal]

So, apparently I sent the previous comment too soon and I can't edit it.

Twitch
https://flic.kr/p/2jehoAk
https://flic.kr/p/2jedjbh

Gmail (because I'm sure there's always something that didn't charge on the first or second shot)
https://flic.kr/p/2jeg5f3

I already reset my profile and Nigthly build change nothing.

It's been happening for a while now, but the last Firefox update made it much worse (on top of everything else).

Comment 4

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Can you provide the exact twitch link where you're not seeing the elements loaded? And also, are they loading correctly on chrome in your case?

I'm attaching what i'm seeing in both https://www.twitch.tv/directory and https://www.twitch.tv/directory/game/Games%20%2B%20Demos, this is reproducible in chrome too so it's related to the website itself not ff.

Best,

Clara

Comment 5

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: element.PNG

Comment 6

[mth.provencal]

No, it doesn't happen on chrome and I just updated firefox (78) and it happens again.

On twitch, it happens everywhere and all the time. I have to reload the same one a good ten times before I can display everything. On both twitch links, it does it. On a live step, there can be three "module loading failures": one for the video, one for the chat, and one under the video. Sometimes the ghost also appears on the channel list on the left.

For the rest, missing elements on "loaded" pages (avatars that don't load on facebook, the facebook css that doesn't load properly, elements/images that don't load on the gmail interface, "missing images" on random sites...), I always have to reload the page several times to be able to display the page properly.

It's been happening for a long time and I'm not the only one. I remember seeing, at the beginning of winter, a reddit post on the subject and another forum talking about it (I should find them again).

So, I repeat, it happens:
everywhere
anytime
random (except for twitch, facebook and gmail where it's pretty standard)
in safe mode and in normal mode
on the nightly version as well as the one I just updated.
even after I reset my profile
even after deleting the cache

And that doesn't happen:
On chrome/chromium
On epiphany
On other browsers for all I know.

Thanks

Comment 7

[mth.provencal]

Attachment: firefox+chrome

Comment 8

[Clara Guerrero ( Need Info Brindusa Tot Please)]

I'm still not able to reproduce, but I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Best regards, Clara.

Comment 9

[Bert Peers [:bpeers]]

Possibly related to this bug, if it's not just UI elements that are erratic:
https://bugzilla.mozilla.org/show_bug.cgi?id=1650246

When elements are missing, are you able to bring them back by scrolling, highlighting them, resizing the window, or other interactions other than a full refresh?

Could you please attach your about:support info (just paste it as a comment)? Thanks.

Comment 10

[Darkspirit]

Please open about:support, click on "copy text to clipboard" and paste it here. This doesn't look like a graphics bug to me, more like it was caused by an addon.

bug 1650246 seems to be some type of widget problem. WebRender correctly works inside it, but is misplaced inside the popup. And only the first paint is misplaced. One small visual change and everything sits correct.

Comment 11

[Darkspirit]

https://appuals.com/failed-to-load-module-twitch/

You may encounter the failed to load module on Twitch due to the corrupt cache of the browser.

https://forums.commentcamarche.net/forum/affich-30064786-echec-du-chargement-du-module
Google Translate:

You have installed adware and parasitic programs on your PC.

File Deleted: C: \ Users \ claire \ AppData \ Roaming \ Mozilla \ Firefox \ Profiles \ t2u12z44.default \ user.js

You should be able to open this folder by opening about:profiles in your address bar and If you find such a user.js file it might be highly interesting what's inside it. I don't have such a file.

https://www.reddit.com/r/Twitch/comments/gp3e5w/failed_to_load_module_issue_started_this_week/
https://www.reddit.com/r/Twitch/comments/gqs2av/firefox_browser_issues_recently/fryi9q7/
It seems enabling DNS over HTTPS helped these users, BUT to me it looks more like it is just blocking malicious dns requests.

Comment 12

[Darkspirit]

(Of course it could just be a misconfiguration and nothing malicious. Regular settings are stored in prefs.js.)

Comment 13

[mth.provencal]

Sorry for the delay.

I'm on Linux (as mentioned above), so it's highly unlikely it's a virus issue. Besides, I reinstalled my OS on another computer and the same thing happens (same thing as before the reinstallation by the way). I've already reset my profile(s) enough without it solving anything. I also don't have a user.js file to remove.

Comment 14

[mth.provencal]

Attachment: about:support

It happens again (and more than ever) on the new version.

Comment 15

[christoph.amelung]

This sounds like a problem that I have been experiencing for months - under Linux only, not under Windows.

Setting network.http.rcwn.enabled to "false" fixed it for me.

Ubuntu 20.04.1 LTS
Firefox 82.0

Comment 16

[Dave]

I've been having this issue for months too. Got annoying refreshing so many times to get parts of Twitch to work. So I searched and found this bug, eventually.

I can confirm that setting network.http.rcwn.enabled to "false" has 100% fixed this. Happy Day, thank you. Twitch always loads correctly now.

Firefox 83.0
Linux
Noscript
ublock origin

Comment 17

[Andre]

Attachment: about:support

I'm a Firefox user on Linux as well and setting network.http.rcwn.enabled to "false" also fixed the "Failed to load module" twitch.tv error.

Firefox 83.0 (64-bit)
Pop!_OS 20.10

Comment 18

[Andre]

I'm a Firefox user on Linux as well and setting network.http.rcwn.enabled to "false" also fixed the "Failed to load module" twitch.tv error.

Firefox 83.0 (64-bit)
Pop!_OS 20.10

Comment 19

[Robert Mader [:rmader]]

This apparently isnt't related to WR, so unblocking bug 1491303

Comment 20

[jaime]

Same exact problem, under arch linux, fixed with network.http.rcwn.enabled to "false"

Comment 21

[okseby]

Same problem, same solution.

Comment 22

[Jeff Muizelaar [:jrmuizel]]

Valentin, what are good next steps here?

Comment 23

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

If this is easy to reproduce, could you help us diagnose the issue by recording some HTTP logs:
https://firefox-source-docs.mozilla.org/networking/http/logging.html

Thanks!

Comment 24

[okseby]

I was able to reproduce while logging and refreshed a couple times till it loaded as well for the log.

https://mega.nz/file/W0UwzBjT#2luJfFFlLAfZX-7dX1z5pOnQET7G3FFcR32Tok01s_I

Comment 25

[okseby]

(In reply to okseby from comment #24)

I was able to reproduce while logging and refreshed a couple times till it loaded as well for the log.

https://mega.nz/file/W0UwzBjT#2luJfFFlLAfZX-7dX1z5pOnQET7G3FFcR32Tok01s_I

I also tried LibreWolf which is a fork of Firefox and I tried the same stuff I did to reproduce for the aforementioned log and I couldn't get it to reproduce if that's not helpful I'm sorry I just thought I'd give it a shot and I did check they have rcwn enabled by default as well.

Comment 26

[christoph.amelung]

In case it helps: I had the impression that for me this problem was related to an unreliable WLAN connection. It occurred quite frequently while I was using a rather old b/g/n WLAN router. It happened much less frequently once I started using a brand-new b/g/n/ac WLAN router, and it disappeared nearly completely when I was connected by LAN cable instead of WLAN.
Scrolling down through my ebay watchlist or amazon shopping cart usually reproduced the error.

Comment 27

[okseby]

(In reply to christoph.amelung from comment #26)

In case it helps: I had the impression that for me this problem was related to an unreliable WLAN connection. It occurred quite frequently while I was using a rather old b/g/n WLAN router. It happened much less frequently once I started using a brand-new b/g/n/ac WLAN router, and it disappeared nearly completely when I was connected by LAN cable instead of WLAN.
Scrolling down through my ebay watchlist or amazon shopping cart usually reproduced the error.

I've only used Ethernet and have this issue so i don't think it has anything to do with it.

Comment 28

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

An unreliable network might explain a large portion of these results.
The way RaceCacheWithNetwork works right now is the following:

• If we detected a slow disk in past loads, we immediately try to load both network and disk
• Otherwise, we try to load from cache, and if that doesn't respond soon, we trigger a network load.
• We will use the one request that comes back first, and discard the other one.

The problem here is with a slow cache if the network fails the request fails, even if it would have succeeded when loaded from cache, which seems problematic.

However, the attached logs don't point to the problem above.

Looking at the logs, some of the requests seem to fail with 804b000d == NS_ERROR_CONNECTION_REFUSED coming from nsHttpConnection::Activate [this=7f30dcadfa00] Bad Socket 804b000d

A bit before that happens we have this bit:

2022-01-19 13:05:06.167361 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167368 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Address [13.32.255.181] is blocklisted for host [static.twitchcdn.net].
2022-01-19 13:05:06.167371 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167374 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Address [2600:9000:200c:c400:c:132:48e:f021] is blocklisted for host [static.twitchcdn.net].
2022-01-19 13:05:06.167378 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167374 UTC - [Parent 2: Main Thread]: V/nsHttp sending progress and status notification [this=7f30dd789500 status=804b0007 progress=0/0]
2022-01-19 13:05:06.167381 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167390 UTC - [Parent 2: Main Thread]: D/nsHttp HttpChannelParent::OnStatus [this=7f30dc961090 status=804b0007]
2022-01-19 13:05:06.167397 UTC - [Parent 2: Main Thread]: V/nsHttp HttpBackgroundChannelParent::OnStatus [this=7f30dd79d500]
2022-01-19 13:05:06.167394 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Address [2600:9000:200c:4800:c:132:48e:f021] is blocklisted for host [static.twitchcdn.net].
2022-01-19 13:05:06.167403 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167406 UTC - [Parent 2: IPDL Background]: V/nsHttp HttpBackgroundChannelParent::OnStatus [this=7f30dd79d500]
2022-01-19 13:05:06.167406 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167415 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Address [2600:9000:200c:3200:c:132:48e:f021] is blocklisted for host [static.twitchcdn.net].
2022-01-19 13:05:06.167418 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167421 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167426 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Address [2600:9000:200c:6800:c:132:48e:f021] is blocklisted for host [static.twitchcdn.net].
2022-01-19 13:05:06.167431 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
...
2022-01-19 13:05:06.167483 UTC - [Parent 2: Socket Thread]: D/nsSocketTransport   trying address: 2600:9000:200c:6400:c:132:48e:f021
2022-01-19 13:05:06.167496 UTC - [Parent 2: Socket Thread]: D/nsSocketTransport ErrorAccordingToNSPR [in=-5980 out=804b000d]
2022-01-19 13:05:06.167498 UTC - [Parent 2: Socket Thread]: D/nsSocketTransport   after event [this=7f30b998ec00 cond=804b000d]

This indicates no connectivity to static.twitchcdn.net when the failure occurs.
For the channel that fails I also see nsHttpChannel::OnCacheEntryAvailable [this=7f30dc98ea00 entry=7f30dc994860 new=1 status=0] which indicates there was no cache entry for that channel, so it would have failed in any case.

The only theory that involves RCWN is that a previous channel races, and cancels the transaction and that puts the connection/socket in a bad state so that the next attempts fail. I don't see indications of that in the log but it's worth investigating.

Comment 29

[okseby]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #28)

An unreliable network might explain a large portion of these results.
The way RaceCacheWithNetwork works right now is the following:

• If we detected a slow disk in past loads, we immediately try to load both network and disk
• Otherwise, we try to load from cache, and if that doesn't respond soon, we trigger a network load.
• We will use the one request that comes back first, and discard the other one.

The problem here is with a slow cache if the network fails the request fails, even if it would have succeeded when loaded from cache, which seems problematic.

However, the attached logs don't point to the problem above.

Looking at the logs, some of the requests seem to fail with 804b000d == NS_ERROR_CONNECTION_REFUSED coming from nsHttpConnection::Activate [this=7f30dcadfa00] Bad Socket 804b000d

A bit before that happens we have this bit:

2022-01-19 13:05:06.167361 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167368 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Address [13.32.255.181] is blocklisted for host [static.twitchcdn.net].
2022-01-19 13:05:06.167371 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167374 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Address [2600:9000:200c:c400:c:132:48e:f021] is blocklisted for host [static.twitchcdn.net].
2022-01-19 13:05:06.167378 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167374 UTC - [Parent 2: Main Thread]: V/nsHttp sending progress and status notification [this=7f30dd789500 status=804b0007 progress=0/0]
2022-01-19 13:05:06.167381 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167390 UTC - [Parent 2: Main Thread]: D/nsHttp HttpChannelParent::OnStatus [this=7f30dc961090 status=804b0007]
2022-01-19 13:05:06.167397 UTC - [Parent 2: Main Thread]: V/nsHttp HttpBackgroundChannelParent::OnStatus [this=7f30dd79d500]
2022-01-19 13:05:06.167394 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Address [2600:9000:200c:4800:c:132:48e:f021] is blocklisted for host [static.twitchcdn.net].
2022-01-19 13:05:06.167403 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167406 UTC - [Parent 2: IPDL Background]: V/nsHttp HttpBackgroundChannelParent::OnStatus [this=7f30dd79d500]
2022-01-19 13:05:06.167406 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167415 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Address [2600:9000:200c:3200:c:132:48e:f021] is blocklisted for host [static.twitchcdn.net].
2022-01-19 13:05:06.167418 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167421 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
2022-01-19 13:05:06.167426 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Address [2600:9000:200c:6800:c:132:48e:f021] is blocklisted for host [static.twitchcdn.net].
2022-01-19 13:05:06.167431 UTC - [Parent 2: Socket Thread]: D/nsHostResolver Checking unusable list for host [static.twitchcdn.net], host record [7f30e6364060].
...
2022-01-19 13:05:06.167483 UTC - [Parent 2: Socket Thread]: D/nsSocketTransport   trying address: 2600:9000:200c:6400:c:132:48e:f021
2022-01-19 13:05:06.167496 UTC - [Parent 2: Socket Thread]: D/nsSocketTransport ErrorAccordingToNSPR [in=-5980 out=804b000d]
2022-01-19 13:05:06.167498 UTC - [Parent 2: Socket Thread]: D/nsSocketTransport   after event [this=7f30b998ec00 cond=804b000d]

This indicates no connectivity to static.twitchcdn.net when the failure occurs.
For the channel that fails I also see nsHttpChannel::OnCacheEntryAvailable [this=7f30dc98ea00 entry=7f30dc994860 new=1 status=0] which indicates there was no cache entry for that channel, so it would have failed in any case.

The only theory that involves RCWN is that a previous channel races, and cancels the transaction and that puts the connection/socket in a bad state so that the next attempts fail. I don't see indications of that in the log but it's worth investigating.

This makes it all the more confusing as it shouldn't need to race as my drive speed is extremely high as I'm using a PCI Gen 4 NVMe SSD.

And on my Laptop a 2021 Macbook Pro (ARM) I use Firefox without the RCWN flag disabled and the issue doesn't present itself so therefore should discredit the issue being network related.

Comment 30

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

(In reply to okseby from comment #29)

This makes it all the more confusing as it shouldn't need to race as my drive speed is extremely high as I'm using a PCI Gen 4 NVMe SSD.
And on my Laptop a 2021 Macbook Pro (ARM) I use Firefox without the RCWN flag disabled and the issue doesn't present itself so therefore should discredit the issue being network related.

I agree that there seems to be an issue with RCWN. We're still looking into it.

PS. please don't quote large comments if possible.

Comment 31

[Jeff Muizelaar [:jrmuizel]]

Valentin, is there something we can do to make this more actionable?

Comment 32

[cippo1995]

Just a feedback as others.
Same under Fedora 35 but also Ubuntu 20.04, the distro really doesn't matter it just needs to be Linux based for what I see.
It is a long standing issue and usually people says to fix it using DNS over HTTPS and only now I have found this.

Good luck fixing it and have a good day

Comment 33

[Jeff Muizelaar [:jrmuizel]]

Does anyone see this problem on an OS other than Linux?

Comment 34

[cippo1995]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #33)

Does anyone see this problem on an OS other than Linux?

I don't use anymore Windows since last November when I decided to use only Linux systems, so I don't know now, but on Windows for what I recall I have never experienced the failed to load module on Twitch.

As I said, before knowing about this bug my fix was DNS over HTTPS and I remember that I had to do that only on Linux every new install.

Comment 35

[Jeff Muizelaar [:jrmuizel]]

Some people seeing this have reported setting network.dns.disableIPv6 fixes the problem. Does that setting fix the problem for anyone on this bug?

Comment 36

[kaimast]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #35)

Some people seeing this have reported setting network.dns.disableIPv6 fixes the problem. Does that setting fix the problem for anyone on this bug?

It's hard to test, because, at least for me, it does not happen frequently.

I disabled ipv6 for my setup just now and will let you all know if I still see this issue in a few days...

Comment 37

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

(In reply to Jeff Muizelaar [:jrmuizel] from comment #31)

Valentin, is there something we can do to make this more actionable?

I can't figure out why this is happening.
My best solution for this would be a speculative fix where we don't cancel the network request.

Dragana, what do you think?

Comment 38

[Per Melin]

I've always had "Failed to load module" on around 50% of page loads on Twitch. But I enabled network.dns.disableIPv6 and after >30 page loads it hasn't happened once.

I saw that FF was doing lookups for A and AAAA in parallel. Twitch hosts don't have AAAA records. Sounds like a good source for a race condition, so I cleared the cache and toggled IPv6 lookups back on again to test that theory while tracing DNS traffic. But Twitch still loads perfectly every time now.

Comment 39

[Dragana Damjanovic [:dragana]]

I would like to understand why this is happening.
It looks like a combination of RCWN and IPv6.

Unfortunately, the log from comment 24 is not available anymore.
May I ask you for another log? Thank you.

Comment 40

[okseby]

(In reply to Dragana Damjanovic [:dragana] from comment #39)

I would like to understand why this is happening.
It looks like a combination of RCWN and IPv6.

Unfortunately, the log from comment 24 is not available anymore.
May I ask you for another log? Thank you.

Ok I've managed to reproduce it and create a new log is it allowed for me to post a link to the file like before? I can't attach it above as its too large.

Comment 41

[Kershaw Chang [:kershaw]]

(In reply to okseby from comment #40)

(In reply to Dragana Damjanovic [:dragana] from comment #39)

I would like to understand why this is happening.
It looks like a combination of RCWN and IPv6.

Unfortunately, the log from comment 24 is not available anymore.
May I ask you for another log? Thank you.

Ok I've managed to reproduce it and create a new log is it allowed for me to post a link to the file like before? I can't attach it above as its too large.

Sure. You could post a link here. Note that the log may contain some privacy information, so you could also write an email and sent it to necko at mozilla dot com.
Thanks.

Comment 42

[okseby]

Ok sounds good, I'll post it here so all can see I'm not too worried about that. I looked into it a little bit and it seems the relevant information seems to start on line 380 if that helps.

Link

Comment 43

[Jeff Muizelaar [:jrmuizel]]

Dragana, does that log show what you're looking for?

Comment 44

[Dragana Damjanovic [:dragana]]

Can you please check the value of pref network.http.fast-fallback-to-IPv4?
In a tab type about:config and click ok on the message that comes up. Then search for "network.http.fast-fallback-to-IPv4"

Comment 45

[Dragana Damjanovic [:dragana]]

This bug may be a mix of 2 issues. The first one sound like bug 1756471. The second is connected to IPv6 addresses.

The log shows that firefox tries IPv6 address that does not work and gets a connection error. The browser has only one single IPv6 address received from DNS resolution. Firefox has a mechanism to fall back to IPv4 but it does not, hence I am asking in comment 44 if the pref is disabled.

Comment 46

[Per Melin]

(In reply to Dragana Damjanovic [:dragana] from comment #45)

The log shows that firefox tries IPv6 address that does not work and gets a connection error. The browser has only one single IPv6 address received from DNS resolution. Firefox has a mechanism to fall back to IPv4 but it does not, hence I am asking in comment 44 if the pref is disabled.

I suffered from this bug until I turned on network.dns.disableIPv6 and my network.http.fast-fallback-to-IPv4 is true (default) and I'm 100% sure that I've never touched it.

Comment 47

[Vincent Lefevre]

I have a similar issue (possibly the same cause), but apparently only with the Debian package, not the official tarball (or perhaps I haven't tried long enough):

• Mozilla bug 1745150 (random immediate connection failures)
• Debian bug 991134 (firefox: random connection failures / possible cache issues)

Also possibly related to non-working IPv6, but like above, why is the IPv4 address blocklisted in the first place?

Comment 48

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

Redirect needinfos that are pending on inactive users to the triage owner.
:dragana, since the bug has high priority and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 49

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

We've landed some changes to both RCWN and IPv6 in the past year, so it's very possible that this is fixed now.
If anyone is still seeing this issue, please let us know and provide some fresh HTTP logs. Thanks!