Fix WebView stuck on server (5xx) error during login (AB#3408586), Fixes AB#3408586#3159
Fix WebView stuck on server (5xx) error during login (AB#3408586), Fixes AB#3408586#3159fadidurah wants to merge 2 commits into
Conversation
When the embedded WebView auth flow received a server-side HTTP error (5xx) on the main frame, onReceivedHttpError only logged and tracked the error without dismissing the loading spinner or invoking an error callback, leaving the user stuck on the login screen indefinitely. This surfaces the error to the caller (stops loading + sends a ClientException via the completion callback) for main-frame 5xx responses, gated behind a new default-on flight FailWebViewFlowOnServerHttpError so it can be disabled via ECS if needed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
✅ Work item link check complete. Description contains link AB#3408586 to an Azure Boards work item. |
1 similar comment
|
✅ Work item link check complete. Description contains link AB#3408586 to an Azure Boards work item. |
There was a problem hiding this comment.
Pull request overview
This PR addresses a UX dead-end in the embedded WebView authorization flow by failing fast on main-frame HTTP 5xx responses (which can prevent onPageFinished from firing), ensuring callers receive an error callback instead of leaving users stuck behind an indefinite loading spinner.
Changes:
- Add a new default-on flight
FAIL_WEBVIEW_FLOW_ON_SERVER_HTTP_ERRORto allow ECS rollback if needed. - Update
AzureActiveDirectoryWebViewClient.onReceivedHttpErrorto invokesendErrorToCallbackfor main-framestatusCode >= 500when the flight is enabled. - Add unit tests covering main-frame vs subresource, 4xx vs 5xx, and flight on/off behavior.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| common4j/src/main/com/microsoft/identity/common/java/flighting/CommonFlight.java | Adds a new default-on flight to gate failing WebView auth on server (5xx) HTTP errors. |
| common/src/main/java/com/microsoft/identity/common/internal/ui/webview/OAuth2WebViewClient.java | Makes sendErrorToCallback protected so the AAD WebView client can reuse the existing error-delivery path. |
| common/src/main/java/com/microsoft/identity/common/internal/ui/webview/AzureActiveDirectoryWebViewClient.java | Detects main-frame 5xx HTTP errors and (when flight-enabled) stops loading and returns a ClientException via the completion callback. |
| common/src/test/java/com/microsoft/identity/common/internal/ui/webview/AzureActiveDirectoryWebViewClientTest.java | Adds unit tests validating the new 5xx main-frame failure behavior and flight gating. |
| changelog.txt | Documents the behavioral change and flight gate in the vNext release notes. |
| mUrlLoadTracker.updateLatestUrlStatus("HTTP Error Code: " + statusCode, null); | ||
| } | ||
|
|
||
| // A server-side error (5xx) on the main frame means the page will never finish loading, |
There was a problem hiding this comment.
@copilot validate this, is this correct?
There was a problem hiding this comment.
The 5xx handling itself is still the intended behavior, but that inline explanation was too absolute. I updated the comment in f5951d0 to say this is the reported failure mode rather than claiming every main-frame 5xx will skip onPageFinished.
Summary
Fixes AB#3408586 — User should not be stuck on the login if server is unavailable.
When the embedded WebView auth flow receives a server-side HTTP error (5xx) on the main frame,
onReceivedHttpErrorpreviously only logged and tracked the error. It never dismissed the loading spinner or invoked an error callback, soonPageFinished(which hides the spinner viaonPageLoaded) was never reached and the user was stuck on the login screen indefinitely.This is asymmetric with network errors (
onReceivedError), which already callsendErrorToCallback. HTTP 5xx now does the same.Root cause
WebViewAuthorizationFragment.launchWebView()shows the progress bar.OAuth2WebViewClient.onPageFinished->onPageLoaded()(hides spinner) is never called.onReceivedHttpErroronly calledmUrlLoadTracker.updateLatestUrlStatus(...), leaving the spinner up forever.Fix
AzureActiveDirectoryWebViewClient.onReceivedHttpError: for main-frame requests withstatusCode >= 500, log a warning and callsendErrorToCallback(stops loading + sends aClientExceptionthrough the completion callback).OAuth2WebViewClient.sendErrorToCallback: changedprivate->protectedso the subclass can invoke it.FailWebViewFlowOnServerHttpError(CommonFlight) so it can be disabled via ECS if it causes regressions.Tests
Added 4 unit tests to
AzureActiveDirectoryWebViewClientTest:ClientExceptionAll tests pass (
:common:testLocalDebugUnitTest, JDK 17).