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]]

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]]

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).