Introduction of Local Network Access in Nightly breaks ability to perform Google O Auth from Becky! Internet Mail
Categories
(Core :: Networking, defect, P2)
Tracking
()
| 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:
- Install Becky! Internet Mail
- 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
Updated•7 months ago
|
Comment 1•7 months ago
|
||
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.
| Assignee | ||
Updated•7 months ago
|
| Assignee | ||
Comment 2•7 months ago
|
||
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?
Updated•7 months ago
|
| Reporter | ||
Comment 3•7 months ago
|
||
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.
| Assignee | ||
Comment 4•7 months ago
|
||
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!
| Reporter | ||
Comment 5•7 months ago
|
||
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.
Comment 6•6 months ago
|
||
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.
Updated•6 months ago
|
Updated•6 months ago
|
| Assignee | ||
Comment 7•6 months ago
•
|
||
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.
| Assignee | ||
Comment 8•6 months ago
•
|
||
Hello Łukasz
Could you please confirm if the issue is not seen with latest nightly?
| Reporter | ||
Comment 9•6 months ago
|
||
I confirm this is fixed in Nightly 145.0a1 (2025-09-20). Thanks!
Updated•6 months ago
|
Updated•6 months ago
|
Comment 10•6 months ago
|
||
Set release status flags based on info from the regressing bug 1960627
Description
•