Open Bug 668577 Opened 13 years ago Updated 5 months ago

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

Categories

(Firefox :: General, defect)

defect

Tracking

()

People

(Reporter: mpd, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

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.
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
Summary: Feature Request for registerProtocolHandler → registerProtocolHandler should not re-prompt if a protocol handler already exists
> Actual results:
>
> FF prompts again.

On my machine, FF says "Foo has already been added as an application for mailto links."
OS: Other → Gonk
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.
(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.
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?
Assignee: nobody → justin.lebar+bug
Attached patch WIP v1 (obsolete) — Splinter Review
Attachment #603826 - Flags: feedback?(gavin.sharp)
(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 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).
Attachment #603826 - Flags: feedback?(gavin.sharp) → feedback+
> 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.  :)
Attached patch WIP v2 (obsolete) — Splinter Review
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.)
Attachment #603826 - Attachment is obsolete: true
Attached patch Patch v1Splinter Review
Attachment #605431 - Attachment is obsolete: true
Attachment #605506 - Flags: review?(gavin.sharp)
Summary: registerProtocolHandler should not re-prompt if a protocol handler already exists → registerProtocolHandler should not re-prompt if a protocol handler already exists and should provide a "don't bug me again" button
I think using the permissions manager to implement the "remember this decision" checkbox would work quite well.
(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?
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 on attachment 605506 [details] [diff] [review]
Patch v1

I'll have a look at the permissions manager.
Attachment #605506 - Flags: review?(gavin.sharp)
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!  :)
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...
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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).
Attachment #605506 - Flags: review?(gavin.sharp)
(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.)
Attachment #605506 - Flags: review?(gavin.sharp) → review-
> 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
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!
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.
Blocks: 1056860
This hasnt seen activity since 2012, resetting assignee.
Assignee: justin.lebar+bug → nobody
Flags: qe-verify+
Flags: firefox-backlog+
OS: Gonk (Firefox OS) → All
If this had a UX concept, this might actually make a great mentored diamond bug.
Status: ASSIGNED → NEW
Depends on: 1084425
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.
Summary: registerProtocolHandler should not re-prompt if a protocol handler already exists and should provide a "don't bug me again" button → registerProtocolHandler should not re-prompt if a protocol handler already exists and should provide a "don't ask me again" button
(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.
Summary: registerProtocolHandler should not re-prompt if a protocol handler already exists and should provide a "don't ask me again" button → registerProtocolHandler notification should provide a "don't ask me again" button
but how to remove this information .Nightly still ask my about it.


Add ProtoMaill as an application for mailto links
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.
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.

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.

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.

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?

Flags: needinfo?(dtownsend)

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

Severity: normal → S3

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.

Flags: needinfo?(dtownsend)

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.

Flags: needinfo?(dtownsend)

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.

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

See Also: → 1731825

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

(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?

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

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

Flags: needinfo?(dschubert)
See Also: → 1840426

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

Flags: needinfo?(dschubert)
Duplicate of this bug: 1692169

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.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: