668577 - registerProtocolHandler notification should provide a "don't ask me again" button

Status: NEW

(Firefox :: General, defect)

Description

[Michael Davidson]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.803.0 Safari/535.1

Steps to reproduce:

Call registerProtocolHandler - the user accepts and the protocol handler is registered.

Call registerProtocolHandler again with identical parameters.


Actual results:

FF prompts again.


Expected results:

FF should not re-prompt if the user has already prompted.

Comment 1

[Justin Lebar (not reading bugmail)]

This is necessary for Gmail to prompt users to use it as their mailto: handler, as it does on Chrome [1].  This would be a pretty Big Deal, as, unless you set a well-hidden pref in Firefox, mailto: links open your default system mail handler (likely Outlook Express).

[1] http://gmailblog.blogspot.com/2012/02/open-email-links-directly-in-gmail.html

Comment 2

[Justin Lebar (not reading bugmail)]

> Actual results:
>
> FF prompts again.

On my machine, FF says "Foo has already been added as an application for mailto links."

Comment 3

[Michael Davidson]

We don't want FF to say *anything*, or give us an API to see if we're already registered. It would be annoying to see that every time you log in to Gmail.

Comment 4

[Justin Lebar (not reading bugmail)]

(In reply to Michael Davidson from comment #3)
> We don't want FF to say *anything*, or give us an API to see if we're
> already registered. It would be annoying to see that every time you log in
> to Gmail.

Understood.

Comment 5

[Justin Lebar (not reading bugmail)]

Gavin, there are a few things I think we should change about this dialog, but I have a few questions, and I want to get your feedback first.

* Add a "don't ask again" button to the prompt.  If I don't want Gmail to handle my mailto: links, it'll be annoying if it asks every time I log in.

Adding the button is easy enough, but I'm not sure how to allow the user to un-reject a site she has previously rejected, or if we care about that.

I'm also not sure how to keep sites from working around our "don't ask again" button by submitting a slightly different URI.  "Don't  ask again" could mean don't ask again for this [protocol, origin] tuple.  Do you think that's right?

* Make the new protocol handler the default after it's accepted.  At the moment, the prompt is just to allow Gmail to *register* a protocol handler.  The current code then marks the mailto protocol so the next time you click a mailto link, you're presented with a list of protocol handlers including the one you just registered.  (See WebContentConverter.js::registerProtocolHandler.)

I think we should make the new protocol handler the default and be done with it.

What do you think?

Comment 6

[Justin Lebar (not reading bugmail)]

Attachment: WIP v1

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to Justin Lebar [:jlebar] from comment #5)
> * Add a "don't ask again" button to the prompt.  If I don't want Gmail to
> handle my mailto: links, it'll be annoying if it asks every time I log in.

> I'm also not sure how to keep sites from working around our "don't ask
> again" button by submitting a slightly different URI.  "Don't  ask again"
> could mean don't ask again for this [protocol, origin] tuple.  Do you think
> that's right?

Why not tie the decision to the domain making the request, as with e.g. geolocation?

> I think we should make the new protocol handler the default and be done with
> it.

This might make sense. I'm not familiar enough with the UI or common scenarios to say offhand. It seems like this feature could use some UX love in general.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 603826 [details] [diff] [review]
WIP v1

A couple of things look wrong with this patch, did you generate it with hg record or something?

- comment looks misplaced (above registerProtocolHandler?)
- rejectProtocolHandlerButtonAccesskey seems to have been added randomly earlier in the file, rather than next to rejectProtocolHandlerButton

The actual code changes seem fine (making the "already exists" case a no-op rather than prompting).

Comment 9

[Justin Lebar (not reading bugmail)]

> Why not tie the decision to the domain making the request, as with e.g. geolocation?

I think that's fine.

> Adding the button is easy enough, but I'm not sure how to allow the user to un-reject a 
> site she has previously rejected, or if we care about that.

But what about this?  I tried to figure out how to un-deny a site I'd "never share geolocation"'ed, but I haven't found that in our UI yet.  :)

Comment 10

[Justin Lebar (not reading bugmail)]

Attachment: WIP v2

This works sans an implementation of the "No, don't bother me again" button.

I'm not sure how we want to implement this.  For similar things in the past, I've just filled in a pref.  I dunno if we want to do something like that, and whether and how we want to expose this pref to the user.

(I considered exposing whether the page had been "never again"'ed in the page permissions dialog.  But it would make more sense to me to put the never again'ed list with the MIME handlers in preferences -> applications.)

Comment 11

[Justin Lebar (not reading bugmail)]

Attachment: Patch v1

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I think using the permissions manager to implement the "remember this decision" checkbox would work quite well.

Comment 13

[Justin Lebar (not reading bugmail)]

(In reply to Jonas Sicking (:sicking) from comment #12)
> I think using the permissions manager to implement the "remember this
> decision" checkbox would work quite well.

People keep saying not to use the permissions manager, for reasons which have never been made clear to me.

Anyway, if we used the permissions manager, how would one go about reverting a "never allow this page to bug me again" choice?

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

You officially have my permission to use the permissions manager :-)

We don't have very good UI for reverting. The best thing we currently have is the page-info UI where we have a security section. That's where we stuck IndexedDB stuff for example.

Comment 15

[Justin Lebar (not reading bugmail)]

Comment on attachment 605506 [details] [diff] [review]
Patch v1

I'll have a look at the permissions manager.

Comment 16

[Justin Lebar (not reading bugmail)]

So for one thing, the permissions manager appears to do sync SQL on the main thread.  (UpdateDB is called with no indirection from AddInternal.)  I'm not sure I have my own permission to use it, now!  :)

Comment 17

[Justin Lebar (not reading bugmail)]

ATM, the "don't bug me again" button stops the site from requesting another handler for the same protocol.  But the site can still request a handler for a different protocol.

I could expose a permission for "don't allow this page to register custom protocol handlers" in the permissions dialog, but it's unclear whether we'd want to expose "don't allow this page to register mailto handlers" in that dialog...

Comment 18

[Justin Lebar (not reading bugmail)]

Comment on attachment 605506 [details] [diff] [review]
Patch v1

Gavin, what do you think about using prefs, rather than the permission service here?  Using about:config for undoing the "don't bug me again button" is pretty bad, but it's a lot simpler than figuring out how to expose this in the permissions page (or somewhere else).

Comment 19

[:Gavin Sharp [email: [e-mail]]]

(In reply to Justin Lebar [:jlebar] from comment #18)
> Gavin, what do you think about using prefs, rather than the permission
> service here?  Using about:config for undoing the "don't bug me again
> button" is pretty bad, but it's a lot simpler than figuring out how to
> expose this in the permissions page (or somewhere else).

I think we should use the permission manager, because that's what it's meant for. about:config isn't really better than nothing in practice (vast majority of our users don't know anything about it), so we're going to need to figure out how to fix the UI properly anyways (e.g. add an entry to the page info tab, about:permissions, etc.)

Comment 20

[Justin Lebar (not reading bugmail)]

> we're going to need to figure out how to fix the UI properly anyways (e.g. add an entry to the page 
> info tab, about:permissions, etc.)

I need some help figuring this out.

At the moment, we expose a static list of permissions in the permissions manager.

Would we want one permission "Prompt about registering protocol handlers" (*) in the permissions manager?  That makes sense from the perspective of the permissions manager, but not necessarily from the perspective of this feature -- when the user is prompted to add a gmail mailto handler and clicks "no, thanks", she's saying "don't allow Gmail to bother me about mailto handlers," not "I don't ever want to use gmail for any protocol handler."

On the other hand, having N different permissions in the permission manager, "allow this site to prompt me about protocol X handlers" seems sub-optimal.

(*) But with more user-friendly words

Comment 21

[Justin Lebar (not reading bugmail)]

An alternative would be to do the following:

When a page does registerProtocolHandler and the user clicks "no",

 * Leave the default handler for the protocol unchanged.
 * Add the requested handler to Firefox's list, but mark it internally as "not requested."
 * If the origin has any other not requested handlers for the same protocol, delete them.

This way, when you go into the list of protocol handlers, you'll be able to see all the handlers you've been prompted about.  If you want to use some handler that you'd said "no" to, just select it there.

This is good because all the protocol handling logic is together in one pane.  But it's bad because protocols the user said "no" to are remembered here.  I'm not sure that this is a big problem, though -- we have to remember them somewhere.

Guidance here would definitely be appreciated!

Comment 22

[Josh Johnson]

Just checking to see if this is still on anyone's radar.  Justin asked for guidance, but it's unclear who that ask had gone out to.  I personally think his 'alternative' suggestion in Comment #21 seems to make the most sense, as it covers the requirements and presents the same list for remembering handlers as well as removing unwanted ones which makes sense from a user's perspective.

Comment 23

[Georg Fritzsche [:gfritzsche]]

This hasnt seen activity since 2012, resetting assignee.

Comment 25

[Georg Fritzsche [:gfritzsche]]

If this had a UX concept, this might actually make a great mentored diamond bug.

Comment 26

[Gingerbread Man]

This report is about not prompting when the protocol handler exists. When I tested, that was already the current behavior. Its STR specifically says,

"Call registerProtocolHandler - the user accepts and the protocol handler is registered."

Bug 998427 that you marked as a duplicate is about not prompting when the user declines to add the protocol handler. If you're going to repurpose this report to accomplish the same thing, please change its summary accordingly.

Comment 27

[Georg Fritzsche [:gfritzsche]]

(In reply to Gingerbread Man from comment #26)
> Bug 998427 that you marked as a duplicate is about not prompting when the
> user declines to add the protocol handler. If you're going to repurpose this
> report to accomplish the same thing, please change its summary accordingly.

The second part of the title here was:
> and should provide a "don't bug me again" button
... which covers the concern from bug 998427, right?

Adjusted title for the current behavior.

Comment 29

[pawel]

but how to remove this information .Nightly still ask my about it.


Add ProtoMaill as an application for mailto links

Comment 30

[mail]

Bug still exist (Year 2016, Firefox 45).

Workaround with external addon: https://support.mozilla.org/en-US/questions/994658

Still an unsolved problem in Firefox.

Comment 31

[Josh Triplett]

I'm still interested in seeing a fix for this as well.

One thought on permission UI: if the user has refused the request, perhaps it'd make sense to have a single icon for "denied permissions" similar to the geolocation or camera permission icon, that shows "you've denied this site from (doing X and Y)", with a single button that leads to information and the ability to undo that denial".  That icon *shouldn't* open its doorhanger by default; users would have to click on it explicitly.  That seems reasonably discoverable, while remaining unobtrusive when the user wants to leave the permissions denied permanently.

Comment 32

[Travis Fimmel]

To expand on Josh's proposal, some of us prefer not to have this functionality at all and would love to have an option to block all of these notifications.

Similarly to how there's a "Block new requests asking to allow notifications" for push notifications it would be great to have a "Block new requests asking to set as default application" or similar.

Comment 34

[chris.hamons]

Since the last comment was two years ago, my web mail client is showing a banner every refresh apparently due to this issue, so it is still an issue.

Comment 35

[kierenj]

Indeed, something changed with Office 365 recently it seems - every single time I open webmail, I'm prompted. I don't want it. My intuition is that all other similar prompts in Firefox have a 'Block' / 'Don't ask again' option. Is the same possible here?

Comment 36

[mozbugz]

Is there a way to disable this feature completely? It is nothing but useless spam anyway.

Comment 37

[armin]

I was annoyed enough to write an addon: https://addons.mozilla.org/en-US/firefox/addon/app-notification-no-more/
It's four lines of javascript but could be less: https://github.com/adioe3/app-notif-no-more/blob/main/main.js

Comment 39

[Glen B]

It's not clear why these bugs keep getting closed and/or marked as duplicates.

But I wish to add my voice to others and report that this problem still exists, and is showing up with increasing frequency. I use Webmail sites including PM, GMail, Outlook, and others, and I do NOT want to "add any of them as a protocol handler." But my only choice is "ADD", and if I hit the "X" on the far right edge of the popup (and that's, really, what this is, an annoying, invasive popup that cannot be blocked), I get reprompted the next time I enter the site.

This bug is present, and relevant, and highly annoying. Edge, Chrome, and others ALL have a "Do Not Ask Again" option - Why doesn't Firefox???

Comment 40

[Ben]

So after A DECADE this has not been fixed, and now countless millions of Outlook users are presumably getting a banner they can't dismiss unless they allow Web Outlook to handle their mailtos! I suggest upping the priority of this.

A workaround is to go to about:config and use the Toggle button to set network.protocol-handler.external.mailto to false (though of course this prevents all external mailto functionality).

Comment 42

[794632548]

10 years old issue. Workaround:

1. open new tab page address: about:config
2. find variable: network.protocol-handler.external.mailto
3. double-click it to set to false

Comment 43

[Belius]

This bug is heading towards its 11th anniversary, someone please fix it! I share the same sentiment like kierenj above: There should be a tickbox that allows users to permanently block such prompts.

Comment 44

[Kevin Ernst]

Setting network.protocol-handler.external.mailto to false in about:config seems to be an effective workaround… so far.

Comment 45

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

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 11 votes.
:mossop, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 46

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 47

[paul.nulty]

Echoing the sentiments in the all the comments hidden as "metoo", "advocacy" or "offtopic" above. There are a lot of comments online by now about this issue, and maybe an increase in severity might be warranted for a problem that causes an unwanted pop-up every time email is opened?

Comment 48

[Dominic Clifton]

Ok, so I'm 12 years late to the party (June 2023 now), but this is issue is bugging me recently.

Every time I use the web version of outlook / office365 I get the annoying prompt at the top of the screen which wastes screen real-estate and bumps the content down.

Can we simply:

• Add a 'do not ask again for this site' button.
• Display a message that directs users to the config so they change change/undo this if they click 'do not ask again', or show a tooltip or (?) button to reveal the message.
• Improve the config so it shows all the registered protocol handlers and sites AND shows a list of 'blocked' sites and protocol handlers so that the user can remove blocked sites.

What's stopping progress on this for so long? The way forward seems very clear to me.

Comment 49

[Dave Townsend [:mossop]]

(In reply to Dominic Clifton from comment #48)

Every time I use the web version of outlook / office365 I get the annoying prompt at the top of the screen which wastes screen real-estate and bumps the content down.

We introduced a fix specifically for outlook and office365 in bug 1731825. Thomas, is it possible that has regressed or is there some reason this may no longer be working?

Can we simply:

• Add a 'do not ask again for this site' button.
• Display a message that directs users to the config so they change change/undo this if they click 'do not ask again', or show a tooltip or (?) button to reveal the message.
• Improve the config so it shows all the registered protocol handlers and sites AND shows a list of 'blocked' sites and protocol handlers so that the user can remove blocked sites.

What's stopping progress on this for so long? The way forward seems very clear to me.

Fundamentally what is missing is someone being available to spec that all out and implement it. Outlook aside (which as I say we have implemented a targeted fix for) this problem doesn't appear to be common.

Comment 50

[nicolas]

Fundamentally what is missing is someone being available to spec that all out and implement it. Outlook aside (which as I say we have implemented a targeted fix for) this problem doesn't appear to be common.

For the record, this banner also appears in SOGo webmail (part of mailcow, an self-hosting solution for e-mails).

Comment 51

[Dominic Clifton]

(In reply to Dave Townsend [:mossop] from comment #49)

(In reply to Dominic Clifton from comment #48)

Every time I use the web version of outlook / office365 I get the annoying prompt at the top of the screen which wastes screen real-estate and bumps the content down.

We introduced a fix specifically for outlook and office365 in bug 1731825. Thomas, is it possible that has regressed or is there some reason this may no longer be working?

The Outlook site I am required to use is 'outlook.office365.us', which is the USA hosted version. Maybe why I still see it.

Regardless a targeted fix doesn't seem like a good long term strategy as you'll forever be playing whack-a-mole with different domain names, or other matching strategies. What we all seem to need is a solution that always works for every site, including other webmail providers like @nicolas above uses.

How can we get some developer time allocated so a solution is created and included in a nighly firefox ASAP?

Comment 52

[Danny Colin [:sdk]]

As a temporary solution, here's the workaround I'm using. I created a userChrome.css file containing the following:

notification-message[value="Protocol Registration: mailto"] {
  display: none !important;
}

This is going to hide the notification bar for any website asking you to register as the mailto default application. If you don't know how to create a userChrome.css file, you can find more instruction on https://www.userchrome.org/how-create-userchrome-css.html

Comment 53

[Dave Townsend [:mossop]]

(In reply to Dominic Clifton from comment #51)

(In reply to Dave Townsend [:mossop] from comment #49)

(In reply to Dominic Clifton from comment #48)

Every time I use the web version of outlook / office365 I get the annoying prompt at the top of the screen which wastes screen real-estate and bumps the content down.

We introduced a fix specifically for outlook and office365 in bug 1731825. Thomas, is it possible that has regressed or is there some reason this may no longer be working?

The Outlook site I am required to use is 'outlook.office365.us', which is the USA hosted version. Maybe why I still see it.

Probably that's the case yes. Dennis, should we add that domain to the list covered?

Regardless a targeted fix doesn't seem like a good long term strategy as you'll forever be playing whack-a-mole with different domain names, or other matching strategies. What we all seem to need is a solution that always works for every site, including other webmail providers like @nicolas above uses.

Yes, but as long as very few sites cause this issue and so very few users experience it the whack-a-mole approach is all we can justify. If someone in the community wants to step up to do the work I'm sure we'd review the code and ship it.

Comment 54

[Dennis Schubert [:denschub]]

(In reply to Dave Townsend [:mossop] from comment #53)

Probably that's the case yes. Dennis, should we add that domain to the list covered?

Yeah, we should! I filed bug 1840426, and will make sure this happens for the 116 train.

Comment 56

[kyleschattler]

Unfortunately, whack-a-mole continues. This issue is happening on my companies privately hosted instance of outlook, which doesn't seem appropriate to add to a global list within Firefox.

Comment 57

[mahnunchik]

13 years have passed, could you please add a 'do not ask again for this site' button!!!!1

Comment 58

[paul.nulty]

This has started happening again for me. Dialog "Add outlook.office.com as an application for mailto links" appears every time on login to Outlook web client. The dialog is closable but there is no "don't ask again" option. Have to manually close every time on opening email. Firefox for Linux Mint Version 124.0.2 (64-bit) . Setting network.protocol-handler.external.mailto to false still fixes the issue. (I suspect some change either in update or on my system reset this to true and that caused it to recur).

Comment 59

[Dennis Schubert [:denschub]]

Yes, we'll ship the previous MS office workaround again in bug 1889326.

Comment 60

[paul.nulty]

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

Yes, we'll ship the previous MS office workaround again in bug 1889326.

Appreciated. I'm sure they are not making life easy with these constant changes to the MS365 apps.

Comment 61

[particlecore]

It's 2024, 13 years after this nonsense was introduced for the first time, and we still have to go into about:config and set network.protocol-handler.external.mailto to false to get rid of this nagware when we could already have a "don't ask again" like we have for everything else.

Firefox 124.0.2 and Nightly 126.0a1 still suffer from this idiocy, and at this rate it will be another 13 years before anything is actually done.

Comment 62

[Dominic Clifton]

@particlecore I propose that we remove the 'network.protocol-handler.external.mailto' setting and force a Firefox developer to use the Outlook website for a week and I'm sure they'd submit a PR to add 'Don't ask again' within a week. :) Making a PR to delete the existing behavior is probably fairly simple...

Comment 63

[thennothinghappened]

Setting browser.mailto.dualPrompt to true adds a "not now" button, which when pressed won't show the message again. Found this as a new answer here: https://superuser.com/a/1839383/937083
...and on my end works exactly as it should. Given this is apparently a new development I'm assuming we're just waiting on that being set to true by default in an update.