Some sites do not open in 140esr
Categories
(Core :: Networking, defect)
Tracking
()
People
(Reporter: hekoqoto, Unassigned, NeedInfo)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Firefox for Android
Steps to reproduce:
After updating ff from 128esr to 140esr, some sites stopped opening, for example, qwen3.app, temp-mail.io...
It tries to connect for a long time, several minutes, then it writes that the connection timed out.
They can open 1 time out of 100, for example.
I changed all the settings, both doh and http3.
I cleared the cache, created a new profile, tried on another computer and provider.
Everything works through the proxy plugin.
Everything also works in ff 128esr and in other browsers, chrome, chromium, vivaldi...
I checked ff versions before 128 esr and after, and found that this problem appeared in 129.0.
As far as I understand, the network parts of doh, dns, etc. were changed in this version.
All these sites work through cloudflare. Perhaps this is somehow related to this.
This also applies to the mobile version.
In Russia, sometimes sites are blocked, but these sites are not blocked and open in other browsers without additional plugins.
I left a message for support https://support.mozilla.org/ru/questions/1527455 and webcompat https://webcompat.com/issues/170455, but this did not give any results.
Perhaps this message will be useful.
Best regards,
Actual results:
Websites do not open.
Expected results:
Websites should open.
|
||
Updated•3 months ago
|
|
||
Comment 1•3 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox for Android::Browser Engine' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•3 months ago
|
||
All these sites work through cloudflare.
What do you mean by this?
(In reply to :Gijs (he/him) from comment #2)
All these sites work through cloudflare.
What do you mean by this?
Hello!
I mean that all the sites in the ticket and a few more sites work through cloudflare, and maybe this is somehow related to the lack of connection. For some reason it does not want to connect to them via https2, and after http1 it immediately tries to connect to http3, and if http3 is disabled, nothing happens.
This happens starting with version 129.
Best regards,
|
|
||
Comment 4•2 months ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:smayya, since the bug has recent activity, could you have a look please?
For more information, please visit BugBot documentation.
|
||
Comment 5•1 month ago
|
||
I didn't manage to reproduce this issue on Ubuntu 22.04 using Firefox 140.3.0esr. Since the reporter already tried multiple machines, profiles and providers, this may be due to specific network conditions. Marking as qa-not-actionable for now.
|
||
Comment 6•28 days ago
|
||
In Russia, sometimes sites are blocked, but these sites are not blocked and open in other browsers without additional plugins.
It sounds like this is connected to the use of ECH and HTTP/3 ?
Could you check if the problem goes away after you set:
network.dns.http3_echconfig.enabled: false
network.dns.echconfig.enabled: false
in about:config
Please check with https://nightly.mozilla.org/ if possible. Thanks!
|
||
Comment 7•4 days ago
|
||
I think I may also be experiencing this issue, or a similar one - happy to make a separate bug if required - on a windows 11 install, latest normal firefox.
It is intermittent but very noticeable when it does happen and genreally fairly reproducible.
I've got a screen-recording of this happening, whilst I have the dev tools open also.
Using mitmproxy fully alleviates the issue, as does disabling http3. Disabling/setting to false the echconfig options as described above also appears to still allow the issue to occur.
It generally recovers itself when trying again after a short time.
For ref, this impacts most significantly for me, Reddit and LinkedIn.
Happy to get captures and screenshots and whatever else needed to help debug this.
Also to add; I was able to reproduce in a fresh profile w/ no extensions.
|
|
||
Comment 8•4 days ago
|
||
Ah - to add also: I'm on Firefox 144.0.2 (64-bit)
|
|
||
Comment 9•1 day ago
|
||
Could you capture some logs as described at the following link?
https://firefox-source-docs.mozilla.org/networking/http/logging.html
Thanks!
|
|
||
Comment 10•1 day ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #9)
Could you capture some logs as described at the following link?
https://firefox-source-docs.mozilla.org/networking/http/logging.htmlThanks!
Yup, reproduced here: https://share.firefox.dev/4qUopI0 . Image that failed is https://preview.redd.it/tdto4cutfk0g1.jpeg?width=917&auto=webp&s=41837a328946f2f3ac46c795157ab4dc4985acb3
I did this on a fresh Firefox profile w/ no extensions, so all should be there as required?
Looks like it failed on the 8th click. Not sure why the "play" image expansion icon is missing - I don't think it's related(!)
|
|
||
Comment 11•1 day ago
|
||
I also captured this using the Networking Preset as opposed to the HTTP/3 preset I used above, and I focused it down on the issue using ctrl-shift-1/2 to start/stop the profiler appropriately. https://share.firefox.dev/3XoMnxm The failure image here should be https://preview.redd.it/qqm329qoll0g1.jpeg?width=1024&auto=webp&s=dcc243c57077dfcb81fe422da078ece3ca9560d1, but I see a few other failures of this family above that, and they all die at the same time.
|
|
||
Comment 12•1 day ago
|
||
LogMessages — (nsHttp) HttpConnectionUDP::Close [this=16f8934a000 reason=804b000e]
which causes the call to:
LogMessages — (nsHttp) HttpConnectionUDP::Close [this=16f8934a000 reason=80004004]
|
||
Comment 13•7 hours ago
|
||
Hi Richard,
Thanks for the log — it’s very helpful.
I think what’s happening is that the HTTP/3 connection is in the 0-RTT state, but UDP is blocked, so the data can’t be sent out. Unfortunately, our fallback mechanism doesn’t handle this case, which causes the request to time out.
To confirm this, could you open about:config, search for network.http.http3.enable_0rtt, set it to false, and see if you can still reproduce the issue?
If it still occurs, could you capture another HTTP log with network.http.http3.enable_0rtt set to false?
Thanks!
Description
•