1990699 - Sporadic Google Drive load times on Firefox browser - Chrome and Safari work fine

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[Service Desk]

Attachment: console-export-2025-9-24_13-27-47.log

Several users have reported ongoing issues with Google Drive when using the Firefox browser. Specifically, documents and slides often fail to load or display correctly. While clearing the browser cache temporarily resolves the problem, it tends to recur unpredictably, making it a sporadic but persistent issue. Notably, this behavior is isolated to Firefox—users have confirmed that the same problems do not occur when accessing Google Drive via Chrome or Safari.

Comment 1

[Service Desk]

Attachment: Screen Recording 2025-09-24 at 19.43.04.mov

Comment 2

[Andrew Overholt [:overholt]]

Please get in touch in #perf-help on internal Mozilla Slack. We'll need more information to diagnose.

Comment 3

[Bas Schouten (:bas.schouten)]

A profile of the issue occurring could also be helpful, although I personally doubt this is a performance issue as opposed to some kind of networking or compat issue a profile could still provide useful information in order to understand what's going on here.

I don't really seem to reproduce this issue myself.

Comment 4

[Patricia Lawless]

I chatted w/ Vrinda to get a little more info. When using Google Drive, sometimes Gmail and other Google things, Firefox hangs for a while (you see the throbber in the tab spinning). She can clear history/cookies and it will help but only temporarily. She's running Firefox 143.0.1 on MacOS.
She has about 50 tabs open. And at least 1 of them has a very large spreadsheet open - though these don't seem like they should be a problem?

She does not have this problem on Chrome.

While we were on zoom, she ran into the issue when requesting access to a file - she clicked the "Request Access" button and nothing really happened but you could see the throbber in the tab. She took a profile while this was happening: https://share.firefox.dev/4gNiJuR

Comment 5

[Patricia Lawless]

Another profile: https://share.firefox.dev/4pQbczh

Comment 6

[Justin D'Arcangelo [:justindarc]]

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1989432

Comment 7

[Luc Lisi]

Something I have noticed as well ( Justin linked the ticket I've opened above with possibly this same issue ) is that the problem does not persist for me if I open a new incognito browser and sign in. I'm not sure if that is the case for everyone reporting this issue, but it is interesting to note as it might indicate this is something related to cookies or local storage?

Comment 8

[Frank Doty [:fdoty]]

Based on findings that the issue can be resolved by disabling network.http.http3.enable flag and reloading, defaulting to H2 - This is pointing to an HTTP3 issue. Network logs have been collected and shared with the Necko team for investigation

Comment 9

[Pascal Chevrel:pascalc]

I am setting all branches as affected and tracking across the board as I don't see release related information in this bug nor the regression keyword.

Comment 10

[Kershaw Chang [:kershaw]]

Here’s a short summary of what I saw in the log:

• All HTTP/3 connections appear to be blocked. The log messages below indicate that crypto frames were lost.

2025-10-01 22:11:45.172156494 UTC - [Parent Process 44940: Socket Thread]: D/neqo_transport::* [neqo_transport::crypto] Lost crypto frame space=in offset=1514 length=395
2025-10-01 22:11:45.172159179 UTC - [Parent Process 44940: Socket Thread]: D/neqo_transport::* [neqo_transport::crypto] Lost crypto frame space=in offset=0 length=559
2025-10-01 22:11:45.172160644 UTC - [Parent Process 44940: Socket Thread]: D/neqo_transport::* [neqo_transport::crypto] Lost crypto frame space=in offset=559 length=955

• This triggers the fallback mechanism to switch to an HTTP/2 connection.
• We have a bug in the fallback mechanism: the log shows that the fallback connection failed to be created.

2025-10-01 22:11:45.456206054 UTC - [Parent Process 44940: Socket Thread]: D/nsHttp nsHttpConnectionMgr::DoFallbackConnection
2025-10-01 22:11:45.456208740 UTC - [Parent Process 44940: Socket Thread]: D/nsHttp TlsHandshaker::SetupSSL 33c4f0100 caps=0x200011 .SA.....F.[tlsflags0x00000000]drivefrontend-pa.clients6.google.com:443^partitionKey=%28https%2Cgoogle.com%29
2025-10-01 22:11:45.456210449 UTC - [Parent Process 44940: Socket Thread]: D/nsHttp GetH2orH3ActiveConn() request for ent 1668a1940 .SA.....F.[tlsflags0x00000000]drivefrontend-pa.clients6.google.com:443^partitionKey=%28https%2Cgoogle.com%29 found an active experienced connection 33c4f0100 in native connection entry
2025-10-01 22:11:45.456211425 UTC - [Parent Process 44940: Socket Thread]: D/nsHttp GetOrCreateConnectionEntry is coalescing h2/3 an/onymous connections, ent=1668a1940
2025-10-01 22:11:45.456213867 UTC - [Parent Process 44940: Socket Thread]: D/nsHttp TlsHandshaker::SetupSSL 33c4f0100 caps=0x200011 .SA.....F.[tlsflags0x00000000]drivefrontend-pa.clients6.google.com:443^partitionKey=%28https%2Cgoogle.com%29
2025-10-01 22:11:45.456215820 UTC - [Parent Process 44940: Socket Thread]: D/nsHttp GetH2orH3ActiveConn() request for ent 1668a1940 .SA.....F.[tlsflags0x00000000]drivefrontend-pa.clients6.google.com:443^partitionKey=%28https%2Cgoogle.com%29 found an active experienced connection 33c4f0100 in native connection entry
2025-10-01 22:11:45.456217041 UTC - [Parent Process 44940: Socket Thread]: D/nsHttp ConnectionEntry::RestrictConnections 1668a1940 .SA.....F.[tlsflags0x00000000]drivefrontend-pa.clients6.google.com:443^partitionKey=%28https%2Cgoogle.com%29 restricted due to active >=h2

• The cause is related to the anonymous flag. In Necko, we allow coalescing of anonymous connections, but this doesn’t work for fallback connections.
• As a solution, we can allow the fallback connection to coalesce with the anonymous one.

Comment 11

[Kershaw Chang [:kershaw]]

Attachment: Bug 1990699 - Allow fallback to coalescing connection, r=#necko

Comment 12

[Kershaw Chang [:kershaw]]

Attachment: Bug 1990699 - Allow fallback to coalescing connection (for uplifting), r=#necko

Comment 13

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Failed to fallback from HTTP/3 connection to HTTP/2.
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• 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 is straightforward.
• String changes made/needed: N/A
• Is Android affected?: yes

Comment 14

[Kershaw Chang [:kershaw]]

Attachment: Bug 1990699 - Allow fallback to coalescing connection, r=#necko

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

Comment 15

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Failed to fallback from HTTP/3 connection to HTTP/2.
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• 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: Patch is really straightforward.
• String changes made/needed: N/A
• Is Android affected?: yes

Comment 16

[Kershaw Chang [:kershaw]]

Attachment: Bug 1990699 - Allow fallback to coalescing connection, r=#necko

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

Comment 17

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined: Failed to fallback from HTTP/3 to HTTP/2.
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• 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: Patch is really straightforward.
• String changes made/needed: N/A
• Is Android affected?: yes

Comment 18

[Kershaw Chang [:kershaw]]

Attachment: Bug 1990699 - Allow fallback to coalescing connection, r=#necko

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

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e04cde4661e4
https://hg.mozilla.org/integration/autoland/rev/1392f7ffb3d9
Allow fallback to coalescing connection, r=necko-reviewers,valentin

Comment 20

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/9433ae846f3e
https://hg.mozilla.org/releases/mozilla-beta/rev/ecc626c936f7

Comment 21

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/7df1d64341df
https://hg.mozilla.org/releases/mozilla-release/rev/fe810fe08fb0

Comment 22

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/222de6f31e30

Comment 23

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/1392f7ffb3d9

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Attachment: Bug 1990699 - Allow fallback to coalescing connection

Comment 26

[Phabricator Automation]

firefox-esr115 Uplift Approval Request

• User impact if declined: Failed to fallback from HTTP/3 to HTTP/2.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Patch is really straightforward.
• String changes made/needed: n/a
• Is Android affected?: yes