Closed Bug 1983386 Opened 7 months ago Closed 6 months ago

Introduction of Local Network Access in Nightly breaks ability to perform Google O Auth from Becky! Internet Mail

Categories

(Core :: Networking, defect, P2)

Firefox 143
defect

Tracking

()

RESOLVED FIXED
145 Branch
Tracking Status
firefox-esr140 --- unaffected
firefox143 --- disabled
firefox144 --- fixed
firefox145 --- fixed

People

(Reporter: lukasz.golonka, Assigned: smayya)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [necko-triaged] )

Attachments

(1 file)

STR:

  1. Install Becky! Internet Mail
  2. With Nightly as your default browser, try adding a Gmail account to the mail client

Actual behavior:

After logging in and allowing Nightly to access applications on local machine, Becky! displays an error.

Expected results:

Login works.

Additional details:

mozregression bisect results:

41:08.42 INFO: Last good revision: 1f8bd7536973c92275380383289e3b8c512ba8d3
41:08.43 INFO: First bad revision: bcfe73462e29fc9f31e82cb32351d8c37c8914aa
41:08.43 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1f8bd7536973c92275380383289e3b8c512ba8d3&tochange=bcfe73462e29fc9f31e82cb32351d8c37c8914aa

Looking at the push log, this most likely regressed in https://bugzilla.mozilla.org/show_bug.cgi?id=1960627. In several later revisions the login process does not continue however, due to https://bugzilla.mozilla.org/show_bug.cgi?id=1979758

Severity: -- → S3
Flags: needinfo?(smayya)
Priority: -- → P2
Whiteboard: [necko-triaged] [necko-priority-new]

Based on comment #0, this bug contains a bisection range found by mozregression. However, the Regressed by field is still not filled.

:smayya, since you are the author of the changes in the range, if possible, could you fill the Regressed by field and investigate this regression?

For more information, please visit BugBot documentation.

Flags: needinfo?(smayya)
Keywords: regression
Assignee: nobody → smayya
Flags: needinfo?(smayya)

hello Lukasz,
We have fixed https://bugzilla.mozilla.org/show_bug.cgi?id=1979758 couple of weeks ago. Could you please confirm the nightly vesion that has been failing for you?

Flags: needinfo?(lukasz.golonka)
Whiteboard: [necko-triaged] [necko-priority-new] → [necko-triaged]

The O Auth process still fails for me with Firefox Nightly 144.0a1 (2025-08-19) (64-bit). Have you tried the STR with Becky! on your side? If there are any additional debug details I can provide just let me know. I mentioned bug 1979758 only because, due to it, the first version identified by mozregression as non functional cannot be used to test this at all.

Flags: needinfo?(lukasz.golonka)

Hello Lukasz,
Today I tried the STR on my window's machine and reproduce it.
From the first look, I see that the becky errors out as soon as we see prompt for LNA access.
May be the client does not expect a prompt or has some timeout configured(?).
From firefox side this prompt is expected. Luckily this is enabled only for nightly. But we need to fix this before we release it.
I will check how chrome is handling this and reach out to becky developers.
Thanks again for flagging this and reaching out!

Flags: needinfo?(lukasz.golonka)

Thanks for reproducing! The Becky! developer is not very responsive I'm afraid, so it is likely you won't get any response from him. I certainly never did (not a satisfactory one at any rate), even though I am a paying customer.

Flags: needinfo?(lukasz.golonka)

From what I can tell, Google's python OAUTH library opens a local socket, does the auth on a public page, then redirects to the local port.
We then attempt the connection, return NS_ERROR_LOCAL_NETWORK_ACCESS_DENIED (which also closes the socket). The prompt is then accepted, leading to a new socket being created.
However, due to us closing the first socket, the python library doesn't accept another connection, leading to authentication to fail.
This test checks that we only open 1 socket to the localhost server when navigating from a public to private IP.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

This should be fixed by Bug 1988525 as we avoid LNA for top level navigations. But as mentioned in above comment, we need to error before we start the transaction.

Hello Łukasz
Could you please confirm if the issue is not seen with latest nightly?

Flags: needinfo?(lukasz.golonka)

I confirm this is fixed in Nightly 145.0a1 (2025-09-20). Thanks!

Flags: needinfo?(lukasz.golonka)
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Depends on: 1988525
Resolution: --- → FIXED
Target Milestone: --- → 145 Branch
Regressed by: 1960627

Set release status flags based on info from the regressing bug 1960627

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: