1747889 - "Sign in" is not recognized after enabling "Data Visualizer" add-in on office.com with ETP - Standard

Status: VERIFIED FIXED

(Web Compatibility :: Privacy: Site Reports, defect, P3)

Description

[Oana Arbuzov [:oanaarbuzov]]

Attachment: StandardVsDisabled.png

Environment:
Browser / Version: Firefox Nightly 97.0a1 (2021-12-29)
Operating System: Windows 10 Pro

Prerequisites:
ETP - Standard enabled.
Signed into Enterprise Microsoft account.

Steps to Reproduce:

1. Navigate to
2. Open a new blank workbook.
3. Click "Insert" button from "Options" menu and choose "Office Add-ins" option.
4. After "Office Add-ins" popup is displayed, click the "STORE" button.
5. Select "Microsoft Visio Data Visualizer" add-in and add it to the workbook.
6. Observe the "Data Visualizer" popup.

Expected Behavior:
"Sign in" is recognized and available "Flowcharts" are displayed.

Actual Behavior:
"Sign in" is not recognized, even if already sign into Microsoft account.

Notes:

1. Screenshot attached.
2. The issue is not reproducible with ETP disabled.

Comment 1

[Tim Huang[:timhuang]]

I can reproduce the issue. The root cause is that https://login.microsoftonline.com/ doesn't have storage access under https://outlookwebtest-my.sharepoint.com/. So, it cannot access its login credential. This means that the Storage Access API should be called in https://login.microsoftonline.com/ when it's embedded in https://outlookwebtest-my.sharepoint.com/ so that this can work. And a shim is possible to fix this issue.

Comment 2

[Emma Zühlcke [:emz]]

We have an intervention in place, see Bug 1740763. Lowering severity.

Comment 3

[Emma Zühlcke [:emz]]

Tim, could you confirm this intervention is still working? Testing on Firefox stable on PROD RemoteSettings the Data Visualizer still does not seem to recognize the login.
The *,https://login.microsoftonline.com entry is still in place.

Comment 4

[Tim Huang[:timhuang]]

Yes, this is also broken to me. I think they change their auth process because I need to allow the domain https://visio.officeapps.live.com to make it work. Maybe we need to add it to our list.

Comment 5

[Emma Zühlcke [:emz]]

Thanks! Tim, since you're assigned, could you please update the skiplist entries and the respective bugs? Perhaps we can (after testing) just drop the generic entries for the the microsoftonline and live endpoints now?

Comment 6

[Tim Huang[:timhuang]]

Sure thing. I will do that.

Comment 7

[Tim Huang[:timhuang]]

I am not entirely sure if we can drop those two entries. But I can check if it's possible.

Comment 8

[Tim Huang[:timhuang]]

Per my testing, we still need the live.com endpoint to display the avatar icon. So, we couldn't drop it.

Comment 9

[Tim Huang[:timhuang]]

Oh, weird. The Data Visualizer addon works again even without allowing https://visio.officeapps.live.com. Maybe Microsoft change something that doesn't require this allowlist entry anymore.

Comment 10

[Emma Zühlcke [:emz]]

Could you please check again if we still need the allowlist entries for MS login? afaic this is the last remaining bug before we can remove the entries.

Comment 11

[Tim Huang[:timhuang]]

I can no longer access the Microsoft Enterprise test account.

Raul, Calin,

Could you help with testing this? To test if we still need the allowlist entry, you can disable the allowlist by flipping the pref privacy.antitracking.enableWebcompat. And see if the problem still exists after disabling WebCompat interventions.

Comment 12

[Raul Bucata]

Hi Tim. I can still reproduce the issue with the pref set to FALSE in a clean profile. Setting the pref to TRUE (by default) in a clean profile does not present the reported issue, as with ETP set to STRICT, the account sign-in is recognized.

Tested with:

Browser / Version: Firefox Release 113.0.2 (64-bit)/ Firefox Nightly 115.0a1 (2023-05-23) (64-bit)
Operating System: Windows 10 PRO x64

Notes:

1. Reproducible on the latest build of Firefox Nightly and Release.
2. Accessing in a clean profile for the first time with the pref set to TRUE does not present the issue when accessing again with the pref set to FALSE.

Comment 13

[Raul Bucata]

Attachment: pref false vs pref true

Comment 14

[Raul Bucata]

Comment on attachment 9335608 [details]
pref false vs pref true

There was an error when uploading the screenshot
Link: https://prnt.sc/8HxVjJjKZWlp

Comment 15

[Calin Tanase]

Attachment: 3 Strict vs OFF ETP.png

The issue is reproducible for me as well with the pref set to false and Strict ETP.

Tested on:
• Browser / Version: Firefox Nightly 115.0a1 (2023-05-23)
• Operating System: Windows 10

Comment 16

[Tim Huang[:timhuang]]

Attachment: Bug 1747889 - Introduce a shim for resolving Microsoft Office auth issue. r?twisniewski!,#anti-tracking!

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0bb600d92194
https://hg.mozilla.org/integration/autoland/rev/aa5817c60cb0
Introduce a shim for resolving Microsoft Office auth issue. r=twisniewski,anti-tracking-reviewers,webcompat-reviewers,bvandersloot

Comment 18

[Cosmin Sabou [:CosminS]]

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

Comment 19

[Monica Chiorean]

I can still reproduce the issue with the pref ('privacy.antitracking.enableWebcompat') set to FALSE in a clean profile and standard ETP, logged on a microsoft account I still see the "Continue without signing in" using Firefox 141.0b4 on Win11. (Same behavior for pref set to True).
Reopen issue.

Comment 20

[Tim Huang[:timhuang]]

Hi Monica,

Thanks for testing this. I cannot reproduce the same issue even if I disabled "privacy.antitracking.enableWebcompat" using Firefox 141.0b4. I can successfully add the "Data Visualizer" with the proper login state.

Could you please provide the testing screen recording so I can diagnose it? Thanks.

Comment 21

[Monica Chiorean]

I hope you can access it from here https://drive.google.com/file/d/1XZtd5OPwe5S_JiBUHuPH43VACfcLzbuQ/view?usp=drive_link as it is too large to upload to issue. Thank you.

Comment 22

[Tim Huang[:timhuang]]

Oh, I see. The top-level domain differs from the one I added in the shim. We can update that.

Comment 23

[Tim Huang[:timhuang]]

Would you be able to share the test account with me? It looks like I need to access the page to figure out the actual domain there.

Comment 24

[Monica Chiorean]

Account provided in private.

Comment 25

[Tim Huang[:timhuang]]

Attachment: Bug 1747889 - Extend the MicrosoftOfficeAuth shim to cover another excel auth iframe. r?twisniewski!

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/dece71f297d9
https://hg.mozilla.org/integration/autoland/rev/cca9c76b81c3
Extend the MicrosoftOfficeAuth shim to cover another excel auth iframe. r=twisniewski,webcompat-reviewers

Comment 27

[Norisz Fay [:noriszfay]]

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

Comment 28

[Monica Chiorean]

I was able to verify the issue on Win11x64 using Firefox builds 141.0b6 and 142.0a1 using an enterprise account and pref ('privacy.antitracking.enableWebcompat') set to FALSE. For non-enterprise accounts user still reproduces the issue and according to Tim this is expected. Marking issue as verified.