1904168 - DNS over HTTPS causes long buffering in YouTube (2024)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0

Steps to reproduce:

Set "DNS over HTTPS" to "Max Protection", using Cloudflare as a provider, then hard-refresh any video on youtube.
Sometimes it works with default or increased protection, but max protection is the only way it's 100% consistent

Actual results:

There's a consistent 10+ second delay compared to not using DNS over HTTPS. Sometimes it's 30 seconds, sometimes it's more.
In addition to that, the video will keep sometimes freeze at the 20 second mark for a while.
In the network monitor, I see a lot of "NS_Binding_Aborted" for "videoplayback?[...]" which are otherwise absent when DNS over HTTPS is disabled. (See attached screenshot)

Expected results:

The video loads nearly instantly and doesn't pause at the 20 second mark when DNS over HTTPS is completely disabled. This should be the normal behavior

Component: Untriaged → Networking

Product: Firefox → Core

I've been unable to reproduce this locally. Can you check this in a new profile (via about:profiles)?

If it reproduces with a new profile, can you take a network log from about:logging, download the log/profile, and send it to necko@mozilla.org? (you'd probably need to put it somewhere like dropbox, since logs can be large.

If it doesn't reproduce in a new profile, can you check if it's being caused by an extension? (Temporarily disable all extensions).
You can also check what settings you've modified, to see if they're causing it. (You can to about:support and check "Important Modified Preferences"; you can also go to about:config and show only modified preferences, though note a ton of them are modified by the browser itself as part of normal operation, but if you changed any about:config preferences by hand they should show up there.

Thanks!

Flags: needinfo?(cj65535)

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #3)

If it reproduces with a new profile, can you take a network log from about:logging, download the log/profile, and send it to necko@mozilla.org? (you'd probably need to put it somewhere like dropbox, since logs can be large.

I tried with a new profile, and I could reproduce it consistently. I tried on my laptop as well. The only setting I changed was setting the DNS over HTTPS setting to strict + Cloudflare
However, when I tried in a sandbox instance of Windows, I could not reproduce it. I am not sure if it has anything to do with the way sandbox works or not.
I tried to send you the email, but it couldn't get delivered, it says "Your message wasn't delivered to necko@mozilla.org because the address couldn't be found, or is unable to receive mail. ". I tried sending the log as an attachment (~8mb) and as a google drive link as well, but neither worked. I use Gmail if that helps.

If it doesn't reproduce in a new profile, can you check if it's being caused by an extension? (Temporarily disable all extensions).

Just out of curiosity, I tried installing and enabling Ublock Origin and Privacy Badger in the sandbox instance, and I still couldn't reproduce the issue.

You can also check what settings you've modified, to see if they're causing it. (You can to about:support and check "Important Modified Preferences"; you can also go to about:config and show only modified preferences, though note a ton of them are modified by the browser itself as part of normal operation, but if you changed any about:config preferences by hand they should show up there.

I assume this is no loger relevant, but I still checked, and there didn't seem to be anything of importance.

Flags: needinfo?(cj65535)

Sorry, the correct email address is necko@mozilla.com

Could you send the log again?
Thanks.

Flags: needinfo?(cj65535)

(In reply to Kershaw Chang [:kershaw] from comment #5)

Sorry, the correct email address is necko@mozilla.com

Could you send the log again?
Thanks.

Log sent

Flags: needinfo?(cj65535)

I also couldn't reproduce it in a virtual machine. That's why I initially thought it has something to do with hardware acceleration, which is false. But now I see why it worked fine there. For some reason, the DNS provider list for max and increased protection on the VM is empty, so I guess it just never uses secure DNS even for default protection.

I think I found a possible reason for this issue. My provider doesn't support IPv6. If I connect using my phone (IPv6 is supported by my mobile carrier), it fixes the problem even when using "max protection" for secure DNS. I was able to reproduce the problem with 2 different ISPs that don't support IPv6. First using Firefox 127 on Windows 10 and second using Firefox ESR 115.12 on Windows 7.

In all cases I used a new profile with all about:config settings in the default state and no extensions installed. Default protection is not 100% reproducible, only max protection is.

I had DNS over HTTPS enabled through Increased Protection and was having the buffer logo show up, and a refresh usually resolved it instantly. It would happen on many videos but not all.

I tried Quad9 and NextDNS and they both had issues.

Disabling DNS over HTTPS or using the Default Protection resolved the buffering issues.

Hi Reporter,

Could you try to download this test build and see if you can still reproduce this issue? If yes, could you try to get a http log again?

Thanks.

Flags: needinfo?(cj65535)

For those without IPv6 support, please go to about:config and enable the preference network.http.http3.retry_different_ip_family. Then, check if this issue still persists.

Thank you.

(In reply to Kershaw Chang [:kershaw] from comment #10)

Hi Reporter,

Could you try to download this test build and see if you can still reproduce this issue? If yes, could you try to get a http log again?

Thanks.

I tried the build, and it worked flawlessly. I hard-refreshed a couple dozen times and it didn't fail a single time.

For those without IPv6 support, please go to about:config and enable the preference network.http.http3.retry_different_ip_family. Then, check if this issue still persists.

I did that with a new profile using version 127.0.1 . Max Protection seemed to fail less frequently, but it was still like a 50% success rate. Do you need a network log for this as well ?

Flags: needinfo?(cj65535)

I did that with a new profile using version 127.0.1 . Max Protection seemed to fail less frequently, but it was still like a 50% success rate. Do you need a network log for this as well ?

Yeah, a networking log would be very helpful. Thank you.

Assignee: nobody → kershaw

Status: UNCONFIRMED → ASSIGNED

Ever confirmed: true

Assignee: kershaw → nobody

Severity: -- → S2

Status: ASSIGNED → UNCONFIRMED

Ever confirmed: false

Priority: -- → P1

Whiteboard: [necko-triaged][necko-priority-queue]

Assignee: nobody → kershaw

Status: UNCONFIRMED → ASSIGNED

Ever confirmed: true

This is what happened based on the log:

1. We created an HTTP/3 connection to the YouTube site with the IPv6 address, but the connection couldn't be established because IPv6 is not supported.
2. We started another fallback connection.
3. The fallback connection wasn't used because our SpeculativeTransaction only considers NS_BASE_STREAM_CLOSED as a success. Since the SpeculativeTransaction was closed with NS_OK here, the transaction didn't consider this fallback connection as successful.

Assignee: kershaw → nobody

Status: ASSIGNED → UNCONFIRMED

Ever confirmed: false

Assignee: nobody → kershaw

Status: UNCONFIRMED → ASSIGNED

Ever confirmed: true

(In reply to Kershaw Chang [:kershaw] from comment #13)

I did that with a new profile using version 127.0.1 . Max Protection seemed to fail less frequently, but it was still like a 50% success rate. Do you need a network log for this as well ?

Yeah, a networking log would be very helpful. Thank you.

Here's a link with two logs https://we.tl/t-SXzZXUWxpS (the link expires in 7 days)

This is affecting Google Drive too, since its video player uses the YouTube infrastructure in different ways.

Please upload a small MP4 video to Google Drive and try playing it to test if your patch fixes it too.

Original Revision: https://phabricator.services.mozilla.com/D215016

beta Uplift Approval Request

• User impact if declined: Youtube videos may stall
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: N/A
• Risk associated with taking this patch: Low
• Explanation of risk level: This patch only adds another check for the close reason.
• String changes made/needed: N/A
• Is Android affected?: yes

Comment on attachment 9409874 [details]
Bug 1904168 - Make sure fallback connection work,

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Youtube videos may stall
• User impact if declined: Youtube videos may stall
• Fix Landed on Version: 129
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch is very straightforward.

https://hg.mozilla.org/mozilla-central/rev/149729a2c3ba

Status: ASSIGNED → RESOLVED

Closed: 2 days ago

Resolution: --- → FIXED

Target Milestone: --- → 129 Branch

Comment on attachment 9409874 [details]
Bug 1904168 - Make sure fallback connection work,

Approved for 115.13esr.

Attachment #9409874 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+

https://hg.mozilla.org/releases/mozilla-esr115/rev/d80101c053542194d169cfb69802e650748c7f75
Backed out of ESR115 for causing build failures (also backed out Bug 1878510 and Bug 1900191)
Push:
Example:

Flags: needinfo?(padenot)

Flags: needinfo?(padenot)

Flags: needinfo?(dmeehan)

Flags: needinfo?(dmeehan)

Component: Networking → Networking: HTTP