1885527 - Cannot open Microsoft Sway when using Microsoft Office 365 accounts, because the Sway website has an auto-redirect-to-login-page flow that's doomed to land on a broken page; and Firefox follows the redirect, but Chrome blocks it by default

Status: NEW

(Web Compatibility :: Site Reports, defect, P2)

Description

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: sway_ms.gif

Found in

• 125.0a1 (2024-03-14)

Affected versions

• 125.0a1 (2024-03-14)
• 124.0
• 123.0.1
• 115.9.0esr

Tested platforms

• Affected platforms: Windows 10x64, Windows 11, macOS 12, Ubuntu 23.10
• Unaffected platforms: none

Preconditions

• Office 365 account

Steps to reproduce

1. Open https://office.live.com/start/Word.aspx?omkt=en-US&auth=1&nf=1 and log in.
2. Click App Launcher from the top left corner and choose Sway.
3. Enter credentials and continue.

Expected result

• Swai is opened.

Actual result

• Microsoft login page is opened. Entering credentials will only display the login page again.

Regression range

• Last good revision: d48aa0f0aa0bbe69f8eae663be2f5671c41af27c (2020-06-23)
  First bad revision: 1004d422aedb5994f9f2949fd4a4c67bc89e22c7 (2020-06-24)
  Pushlog:
  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d48aa0f0aa0bbe69f8eae663be2f5671c41af27c&tochange=1004d422aedb5994f9f2949fd4a4c67bc89e22c7
  Unfortunately, I don't know which of the issues is the regressor.

Additional notes

• Attached a screen recording.
• This works as expected with free Microsoft accounts.

Comment 1

[Thomas Wisniewski [:twisniewski]]

Paul, is this maybe something we can fix using our Microsoft Login shim?

Comment 2

[Paul Zühlcke [:pbz]]

Yes, it's possible that this can be fixed using the shim.

I can't reproduce the issue because I don't have access to a MS enterprise account. The test account I have here now has 2fa enabled which I don't have the codes of. Could you please either share the credentials you used for testing or attach a network log from the devtools so I can understand better what the redirect flow looks like?

Comment 3

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: swaylogs.zip

(In reply to Paul Zühlcke [:pbz] from comment #2)

Yes, it's possible that this can be fixed using the shim.

I can't reproduce the issue because I don't have access to a MS enterprise account. The test account I have here now has 2fa enabled which I don't have the codes of. Could you please either share the credentials you used for testing or attach a network log from the devtools so I can understand better what the redirect flow looks like?

Hello! It seems that now Sway is correctly opened after closing the new tab and then clicking on Sway again with Firefox 125.0b5. This was not the case when I filled out the issue. Screen recording here.

I have also attached some logs for when the white blank page is displayed by saving all logs as a HAR file. I hope I did it correctly if not please let me know. Thank you!

Comment 4

[Paul Zühlcke [:pbz]]

Thanks for attaching the network logs. I can see the following redirect chain:

login.live.com -> sway.cloud.microsoft -> login.microsoftonline.com -> sway.cloud.microsoft -> sway.cloud.microsoft

I can reproduce (at least something similar?) on Nightly when I directly navigate to https://sway.cloud.microsoft and log in with a non enterprise account. Extending the redirect list for our existing dFPI shim doesn't seem to address the issue. It even reproduces when ETP is toggled off via the shield icon. It also reproduces when I uncheck checkboxes in ETP custom. This is unlikely to be ETP related.
Nothing obvious logged in the console except some samesite lax cookie warnings. Once I reach the blank page at https://sway.cloud.microsoft/home/sso the issue can be fixed by navigating to https://sway.cloud.microsoft again. The login works but it looks like the final automatic redirect doesn't.

Sorry Tom, I think I have to give this one back to you for now.

Comment 5

[Thomas Wisniewski [:twisniewski]]

It's working for me in a fresh Firefox profile with my MSN account, regardless of ETP settings.

However, in an existing profile it wasn't working for me, until I cleared cookies and site data on the login.live.com login page, and tried again. I wonder what's up with that? But maybe that's at least a work-around?

Comment 6

[Dennis Schubert [:denschub]]

Alexandru, is this still broken for you?

Comment 7

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: sway.gif

(In reply to Dennis Schubert [:denschub] from comment #6)

Alexandru, is this still broken for you?

I am seeing something similar but now this happens only the first time when using Sway in that Firefox profile. The Microsoft login page is opened again after clicking sway and then a blank page is displayed after entering the credentials. However, if we return to the application page again and select Sway again it will work. I attached a screen recording of a new Firefox 132.0a1 (2024-09-09) profile.

Comment 8

[Daniel Holbert [:dholbert]]

I can reproduce in a fresh profile using my own Microsoft account, using the same starting URL in comment 4. Works fine in Chrome. "Chrome mask" doesn't seem to help in Firefox.

(FWIW, I'm doing Ctrl+Shift+Del after each attempt, to clear all of my browsing data and get back to a clean slate, since it seems from prior comments that this might not repro if you're already signed in etc.)

My best clue so far about what's going on: comparing the logs in network devtools, the nearly-last-thing that Firefox gets is a request to
https://sway.cloud.microsoft/authredir?url=https%3a%2f%2fsway.cloud.microsoft%3a443%2fhome%2fsso&hurl=[...]

...whereas Chrome gets a request to:
https://sway.cloud.microsoft/authredir?url=https%3a%2f%2fsway.cloud.microsoft%3a443%2fmy&hurl=[...]

Note the %2fhome%2fsso (i.e. /home/sso) in the Firefox URL there, vs. %2fmy (i.e. /my) in the Chrome URL there.

That authredir page redirects to the requested URL (https://sway.cloud.microsoft/home/sso in Firefox vs. https://sway.cloud.microsoft/my in Chrome), and unfortunately https://sway.cloud.microsoft/home/sso is the blank page that's been described here, whereas /my is the actual usable landing page.

So: next question is, why is Microsoft generating that authredir URL with the broken /home/sso redirect-target-URL baked into it (only in Firefox)...

Comment 9

[Daniel Holbert [:dholbert]]

OK, I've got it. The login flow is subtly different here between Firefox and Chrome -- https://sway.cloud.microsoft/ automatically redirects to a login page which happens to be broken, whereas Chrome detects that redirect and blocks it for some reason -- so in Chrome, you have to manually click through to the sign-in UI (e.g. using the avatar icon at the top right). And that login flow is not broken.

When Chrome blocks the redirect, it shows me a notification at the right edge of its address bar, similar to popup-blocked UI (but for a blocked redirect in this case). If I interact with that UI to allow the redirect to happen, and then reload the page, then I get the same experience as in Firefox, i.e. I end up at a blank /home/sso page at the end of the login flow.

So, there are two action items here:
(1) Figure out why Chrome is blocking that redirect vs. why we're not? (I'm not sure offhand if we even have the same sort of redirect-interception mechanism as they do; but if we do, it'd be good to see why ours isn't activating here.)
(2) Notify Microsoft that the https://sway.cloud.microsoft automatic redirect is unfortunately dropping users into a broken flow (regardless of browser, if the user/browser permits the redirect).

jesup, maybe you or someone on the networking team could help answer (1) here? That seems to be the proximal webcompat behavior-difference that's triggering this issue.

Comment 10

[Daniel Holbert [:dholbert]]

[Sorry, meant to ni=jesup for comment 9; doing that now]

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: screenshot of "popups and redirects" settings UI in Chrome, and "redirect blocked" UI in the location bar

Here's a screenshot showing the relevant settings UI (with its default value) in Chrome, at chrome://settings/content/popups, and the "redirect blocked" notification/button that it ends up producing in the address-bar when I visit https://sway.cloud.microsoft