1709653 - outlook365 prompting to add mailto links on every refresh

Status: REOPENED

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

Description

[Stephen Pierce]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

I am repeatedly getting a notification bar asking me to add outlook as a mailto handler. Happens after resuming from sleep, hitting refresh, etc. Gmail prompted once and hasn't asked again, so it may be site specific.

Actual results:

I click the 'x' on this popup, but my preference is apparently not remembered

Expected results:

I would like to permanently disable this popup like I can with the notification/camera/microphone permissions

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Audio/Video' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Byron Campen [:bwc]]

So this is definitely not a webrtc thing. Maybe this is a uriloader thing, which is under Core::Document Navigation according to the modules page, but that component does not seem to exist in bugzilla. Moving this to the most generic-looking submodule under DOM instead.

Comment 3

[Kershaw Chang [:kershaw]]

This looks like a cookie bug, since the user's preference is not saved.

Comment 4

[Stephen Pierce]

Attachment: image.png

Comment 5

[Stephen Pierce]

Does firefox inject a cookie to save this preference?
The prompt is a firefox element, not part of the webpage.
Still seeing the issue in v 89.0

Comment 6

[Michelle Goossens [:masterwayz]]

This has started to happen to me as well, I'm on v91.0.2

Comment 7

[Kershaw Chang [:kershaw]]

(In reply to Stephen Pierce from comment #5)

Does firefox inject a cookie to save this preference?
The prompt is a firefox element, not part of the webpage.
Still seeing the issue in v 89.0

I thought outlook.com should use a cookie to save this preference, but it's not the case.
I took another look and it seems that when I clicked x button, there was no cookie saved. So, this has nothing to do with cookies.

All I know is that this notification bat is triggered from WebProtocolHandlerRegistrar.jsm, so I'd like to change the component to Firefox:Gereral, which is the same as bug 1499092.

Comment 8

[B.J. Herbison]

Some users have mentioned this issue recently in the Matrix. Most recently: https://matrix.to/#/!OjiTSQTpPWGpfDenKT:mozilla.org/$MCnzkULngzjdqotgYOnbJRQo7ztZo2oj5o8bcy01Wpw?via=mozilla.org&via=matrix.org&via=privacytools.io
#fx-desktop-community:mozilla.org

Comment 9

[Martin Thomson [:mt:]]

I wanted to add my own discovery: granting the permission does not immediately cause outlook to become the handler for mailto links. The next mailto link "navigation" will result in Firefox showing a dialog, where the site becomes one of many options. You can select some other service (such as the OS default) from that dialog. You can also make this choice pre-emptively in about:preferences.

That is, it's safe to allow Outlook to register as a protocol handler.

There are a few things that Firefox might do better here:

1. make it possible to block this sort of request

2. make it clear that allowing a site to handle a "protocol" like this doesn't commit you to having that protocol handled by the site

Comment 10

[Daniel Bodea [:danibodea]]

I have reproduced this issue using these steps:

1. Log into Outlook Microsoft 256 with a test account.
   Observe: The <<Add "outlook-sdk.office.com" as an application for mailto links?>> info bar is displayed.
   It has an "Add" button and an 'x' button.
2. Click the info bar's 'x' button.
3. Refresh the page.
   Actual result: The info bar appear again.
   Expected result: The info bar does not appear again.

This behavior is seen in ALL the latest versions of the main channels: Nightly v93.0a1, Beta v92.0 RC3, Release v91.0.2, ESR v78.13.0esr and v91.0.1esr.
It also reproduced in older Nightlies: v75.0a1, v65.0a1 and v55.0a1... I'll stop here as it does not make sense to test further (older builds).
This proves that the recent change that causes this issue to emerge is not on the browser side, but more probably on the web app side.

Chrome behavior in this situation:

1. Log into Outlook Microsoft 256 with a test account.
   Observe: Chrome also shows a door hanger requesting to allow using this app for the mailto links, that the user can allow, block or dismiss ('x' button).
2. Click the info bar's 'x' button.
3. Refresh the page.
   Result: The door hanger is not shown again.
   Considering this behavior we can say that Chrome does not show this issue.

Moreover, I have to mention that I am not sure what the expected behavior of this info bar is. Clearing that up might help us test further.
I have chosen the Messaging Systems component since the issue is related to that info bar, but please set a better one if incorrect.

Comment 11

[Dave Townsend [:mossop] (PTO until July 20)]

I think this is a website issue so not a bug in Firefox, though we have added a workaround in bug 1731825.

Comment 12

[Thomas Wisniewski [:twisniewski][on PTO until July 6]]

Pardon the spam, but I'm reopening this issue as we're changing how we track issues currently resolved by a webcompat intervention (by leaving them open until the underlying issue is fixed).

Comment 13

[adryd]

Heyo, the current workaround for this bug is causing Microsoft Office online and OneDrive to stop working.

/* ... */

const proto = Object.getPrototypeOf(navigator).wrappedJSObject;
const { registerProtocolHandler } = proto;
const { localStorage } = window.wrappedJSObject;

/* ... */

Object.getPrototypeOf(navigator).wrappedJSObject is undefined
and for some reason its running in the global scope, so const { localStorage } = overwrites localstorage everywhere

This makes these sites very angry. The pages won't load and the logs are filled with Uncaught ReferenceError: can't access lexical declaration 'localStorage' before initialization

Comment 14

[Thomas Wisniewski [:twisniewski][on PTO until July 6]]

@adryd, that looks like older code we have since updated (this is how it looks now). Could you please confirm which version of the Web Compatibility Interventions addon you see when you visit the URL about:support (and also the version of Firefox, in case it's an older one)?

Comment 15

[adryd]

I'm on Firefox 148.0.2 (shipped by fedora) and the webcompat version in about:support is 148.7.0

Comment 16

[adryd]

hmm, creating a new profile absolves the issue. I'm not sure why the old webcompat stuff is still loading in my profile. I'm going to assume that the bug isn't related to this issue and y'all can disregard

Thank you for the help.

Comment 17

[Thomas Wisniewski [:twisniewski][on PTO until July 6]]

@adryd: Ah, interesting. We shipped that change relatively recently, and you should have received it by now. While you should get it in your normal profile by default in Firefox 149 (due to release around March 24), you can also try to update the webcompat addon sooner to version 149.7.20260211.154938 by using the steps I outlined in bug 2000906 comment 27.

Comment 18

[samlh]

Outlook is now available at a new url, which doesn't seem to have the mitigation applied:
https://outlook.cloud.microsoft

(the intervention does seem to be working fine for the older outlook urls)

See https://learn.microsoft.com/en-us/microsoft-365/enterprise/cloud-microsoft-domain?view=o365-worldwide for more info about the new domain.

Unless I'm misreading, it looks like this file is where the list of domains is located:
https://searchfox.org/firefox-main/source/browser/extensions/webcompat/data/interventions/1889326-Office_365_email_handling_prompt.json

Would it be possible to have the new domain added?

Thanks in advance!

Comment 19

[Thomas Wisniewski [:twisniewski][on PTO until July 6]]

Yes, we can do that. Thanks for the heads-up!

Comment 20

[:Gijs (he/him)]

(In reply to Thomas Wisniewski [:twisniewski] from comment #19)

Yes, we can do that. Thanks for the heads-up!

Hi Tom, is there a separate bug for this? I have recently had the dubious honour of being given one of these and am now seeing this myself. I notice the file linked in comment 18 has not been updated to include https://outlook.cloud.microsoft/ yet.

Comment 21

[Thomas Wisniewski [:twisniewski][on PTO until July 6]]

Yes, this is on my docket for hopefully landing next week. I'll just add the patch to this bug and we'll leave it open until the underlying issues are resolved, as usual.

Comment 22

[Thomas Wisniewski [:twisniewski][on PTO until July 6]]

Attachment: Bug 1709653 - add outlook.cloud.microsoft to the list of sites covered by our Outlook365 mailto webcompat intervention; r?ksenia

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/589f6be38e30
https://hg.mozilla.org/integration/autoland/rev/4e998abf66e6
add outlook.cloud.microsoft to the list of sites covered by our Outlook365 mailto webcompat intervention; r=ksenia,webcompat-reviewers

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/7ac74b9885bd
https://hg.mozilla.org/mozilla-central/rev/270bc95720d1
add outlook.cloud.microsoft to the list of sites covered by our Outlook365 mailto webcompat intervention; r=ksenia,webcompat-reviewers

Comment 25

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/270bc95720d1

Comment 26

[Takanori MATSUURA]

Depends on: 665877

Does this mean that the bug should be fixed by implementing a notification dismissal mechanism instead of through webcompat intervention?

Comment 27

[Jeff Muizelaar [:jrmuizel]]

I think so yes. That would match Chrome.