1616596 - identity.launchWebAuthFlow sometimes is getting stuck while detecting the redirect_uri and then be resolved after a while

Status: VERIFIED FIXED

(WebExtensions :: Request Handling, defect, P1)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

This issue seems similar to Bug 1528562, but the fix for Bug 1528562 doesn't cover this additional scenario yet (and the existing test case doesn't trigger it because it is using a POST but it is pointing it directly to the redirect_url, instead of receiving a POST reply and then navigating to the redirect_uri because of the Location header).

While trying to trigger the same issue I'm able to trigger while trying identity.launchWebAuthFlow on a local test oauth server (using https://github.com/14gasher/oauth-example to run a demo oauth server locally), I noticed that our test case should already be testing exactly the scenario described above (POST http request + redirect due to a Location header in the POST http reply) and I've not been yet able to figure out what is different between what happens in the test case (which pass successfully with and without my patch) and when I trigger the issue on the local oauth demo server (where identity.launchWebAuthFlow is getting stuck without my patch).

Comment 1

[Luca Greco [:rpl] [:luca] [:lgreco]]

Another really odd behavior of this issue (something that I noticed yesterday while trying to get more details when the issue is being triggered) is that a pretty long time (not just some seconds or milliseconds) the redirect is actually detected and the API call resolved with the expected url if I leave the auth dialog open.

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 1616596 - Use ChannelWrapper and nsIHttpActivityDistributor to detect when identity.launchWebAuthFlow dialog is being navigated to the redirect_uri. r?mixedpuppy!

Comment 3

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: nsHttp-logs-when-identityflow-got-unstuck.txt

I'm attaching some additional logs that I collected using MOZ_LOG="nsHttp:5".

At a first glance it seems that, while the identity.launchWebAuthFlow dialog is stuck, there is an "half open socket" pending for the redirect url and when the identity.launchWebAuthFlow gets finally resolved we have given up on the "half open socket" and the connection is being recreated in a way that finally trigger the onStateChange listener.

Comment 4

[tom]

FWIW, we're seeing delays of up to 30 seconds with older versions of our extension as well as newly build ones on ff740.b9.
we hope ff74 is not going live until this one has been fixed, because it would expose our user base to those delays - something they certainly would blame us for.

Comment 5

[Christopher Arnold]

(In reply to tom from comment #4)

FWIW, we're seeing delays of up to 30 seconds with older versions of our extension as well as newly build ones on ff740.b9.

Thank you for confirming that you can replicate Tom. Could you post steps to replicate here so others of us can test?

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cca1d61d1a7f
Use ChannelWrapper and nsIHttpActivityDistributor to detect when identity.launchWebAuthFlow dialog is being navigated to the redirect_uri. r=mixedpuppy

Comment 7

[Shane Caraveo (:mixedpuppy)]

[Tracking Requested - why for this release]: This was identified on 74 too late, but it should be fixed if we get a dot release.

Comment 8

[Shane Caraveo (:mixedpuppy)]

STR from reporter in comment 4, requires credentials provided via email:

With mailcheck 5.0:

steps to reproduce:

1. turn off password management in preferences
2. install xpi via addon debugging page
3. click on browser action button
4. type in user credentials; 1) submit email address, this triggers 2) the auth web flow;

after submitting the credentials; you should see a delay no longer than a second before you're done and email polling starts

Comment 9

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/cca1d61d1a7f

Comment 10

[tom]

good job, thank you.

Comment 11

[Alex Cornestean]

Hello,

Verified the fix on the latest Nightly (76.0a1/20200310094445) under Windows 10 Pro 64-bit and MacOS Catalina 10.15.

After inputting the credentials as per the STR from Comment 8 and clicking the “Login” button, the authentication window closes immediately and email polling starts, confirming the fix.

Comment 12

[Luca Greco [:rpl] [:luca] [:lgreco]]

Comment on attachment 9129189 [details]
Bug 1616596 - Use ChannelWrapper and nsIHttpActivityDistributor to detect when identity.launchWebAuthFlow dialog is being navigated to the redirect_uri. r?mixedpuppy!

Beta/Release Uplift Approval Request

• User impact if declined: Users may experience a considerably delay when an extension is using the identity.launchWebAuthFlow API method to retrieve the oauth token.

The delay may be quite long and the user may decide to close the oauth dialog before the authentication flow is completed (which would reject the API call and prevent the extension from working as expected).

• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Yes, this should be verified explicitly by QA, because the change is covered by automated tests (which prevents regressing the existing behaviors) but this particular issue scenario is not yet covered by an automated test.

The STR to use are the same used to verify the fix on Nightly (See Bug 1616596 comment 8).

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change is small enough and restricted to the part of the identity API implementation that detects when the oauth dialog is starting a navigation to the expected redirect_uri.

The API is covered by automated tests (which would prevent to regress the other expected behaviors), and the fix for this particular issue has been explicitly verified by QA (and from the developer of one of the affected extension) on Nightly.

• String changes made/needed:

Comment 13

[Julien Cristau [:jcristau]]

Comment on attachment 9129189 [details]
Bug 1616596 - Use ChannelWrapper and nsIHttpActivityDistributor to detect when identity.launchWebAuthFlow dialog is being navigated to the redirect_uri. r?mixedpuppy!

approved for 75.0b2

Comment 14

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/releases/mozilla-beta/rev/0791937bf122

Comment 15

[Alex Cornestean]

Hello,

Sorry I forgot to mention it yesterday, but I was able to consistently reproduce the issue at hand as per the provided STR on Beta 75.0b1 (75.0b1/20200309155231) and Release 74.0 (74.0/20200309095159) under Windows 10 Pro 64-bit and MacOS Catalina 10.15.

Furthermore, I have verified the fix on the latest Beta (75.0b2/20200310192828) under Windows 10 Pro 64-bit and MacOS Catalina 10.15. After inputting the credentials and clicking the “Login” button, the authentication window closes immediately and email polling starts, confirming the fix.