Closed Bug 1631464 Opened 2 years ago Closed 1 year ago

Remove the title argument from registerProtocolHandler()

Categories

(Core :: DOM: Navigation, defect, P3)

defect

Tracking

()

RESOLVED FIXED
84 Branch
Tracking Status
firefox84 --- fixed

People

(Reporter: fredw, Assigned: fredw)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete, site-compat)

Attachments

(2 files)

This is currently being discussed at https://github.com/whatwg/html/pull/5425 and Anne said Firefox is interested. PR for WPT tests are available in the "see also" link but maybe we have more internal tests.

WebExtension's https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers has a "name" key but I assume this is orthogonal to registerProtocolHandler()'s title so removing the latter won't break the latter (I haven't tried to change the code so it's just guessing for now).

Depends on: 1627202
See Also: 1627202
Blocks: 1056860
Keywords: site-compat
Depends on: 1632787
Priority: -- → P3

Should the patch be reviewed by someone?

Flags: needinfo?(fred.wang)

Right. Try server looked ok last week, but I was waiting for the new WPT test to be imported and the IDL WPT tests to be updated before asking for review. Besides tests, the patch should be ready though.

Flags: needinfo?(fred.wang)
Depends on: 1631900

WPT tests have synchronized, so I'm asking for review now.

It turned out that the "title" argument is actually used when you try and open the link, I get a window link this:

[ Launch Application

This link needs to be opened with an application

TITLE https://URL
...

Choose another Application.

Remember my choice for web+foo links

[Cancel] [Open link]
]

I updated my patch to use the document's title instead.

Should that read TITLE web+foo:URL or am I missing something? Something like "Use example.com to open web+foo:URL" (i.e., replace TITLE with the host) would make sense to me in terms of UI. If we use the title of the document there's still some opportunity for spoofing, even if it's only shown after the user added the handler.

Flags: needinfo?(jhofmann)
Attached image mailto.png

Sorry I was not clear, here is a screenshot (Nightly is the item registered by the page).

I'm a bit puzzled about this and the spec change, when the title is used in the UI.

Flags: needinfo?(annevk)

I did not realize we had the title in our UI, but it's not clear to me that it's a good idea as it can be used to mislead the user (e.g., trying to trick them something is Thunderbird when it's really not). I think we should only state the origin (perhaps without https:// as that's required anyway) for sites and use names for installed applications.

Flags: needinfo?(annevk)

Sorry for the delay on this. I would say that the title definitely adds some user value (looking at Yahoo! Mail I can certainly see my less tech-savvy relatives understanding that vs. compose.mail.yahoo.com) but OTOH I agree that displaying arbitrary strings from the web in chrome UI isn't really what we'd do nowadays if we were to reimplement this.

If the other major browsers aren't showing a title either I can certainly see us removing that, otherwise it might be a more complicated discussion. Gijs, any thoughts?

Flags: needinfo?(jhofmann) → needinfo?(gijskruitbosch+bugs)

We removed the title from the message asking to add the protocol handler already, for security reasons (bug 1490276).

If the user has still installed it, based on that message which only lists the origin, I don't think anything we do after that point is going to be useful to protect the user. Getting rid of the name in the dialog makes the dialog harder to use for extension protocol handlers and for the handlers we pre-ship, and the obvious next question is "well, what about the favicon? Should we remove that too?" because of course, if the name is not spoofable, that will be next... Then we're left with a dialog that makes web options seem like complete gobbledygook to users, in favour of native apps, which I don't think is the web we want.

Also, the patch as attached removes the argument from the registerProtocolHandler API, but then registers the protocol with the browser title as the name, which is just as spoofable and less likely to fit in the dialog for benign usecases, and will include "Mozilla Firefox" on some OSes -- that's just wrong.

Flags: needinfo?(gijskruitbosch+bugs)

Thanks Gijs, I agree with you, I think.

Also, the patch as attached removes the argument from the registerProtocolHandler API, but then registers the protocol with the browser title as the name, which is just as spoofable and less likely to fit in the dialog for benign usecases, and will include "Mozilla Firefox" on some OSes -- that's just wrong.

Yeah that seems like a worse solution than not showing the title.

Severity: -- → S3

I agree the current patch's option is not good (I'm happy to change to a better title in the UI) but I'm still a bit confused by the replies here.

IIUC, there was a consensus among browser vendors (at least Mozilla, Microsoft and Google) that the title parameter should be removed, so it's no longer in the HTML5 spec and this is tested by WPT test. But now it seems some Mozillians disagree... Should requesting we revert this change? Do you plan to discuss this at WHATWG again? Or otherwise how do you suggest to implement the current HTML5 text?

I personally don't care much about this change, but I feel bad that I started to help do the implementation work in Gecko/Chromium and now things just get stuck.

Flags: needinfo?(annevk)

Apologies for not following up sooner Frédéric.

I think we should use the origin as title (shortened by dropping the scheme as we require a secure context) and also display the registered scheme so it's clear which site will handle what. We can still use non-origin titles for privileged applications that are supported by Firefox (e.g., Yahoo! Mail and Gmail appear to have dedicated support) or are added by extensions.

More detailed discussion of our current UI:

  • In about:preferences under General -> Applications we list schemes (but call them content types as they are grouped with MIME type handlers) and potentially a non-origin title (though the default is "Always ask" so you might not see the title all that much). I think it would be clearer to have origins listed here that can handle the custom schemes. Longer term we probably want to separate custom scheme and MIME type handlers as the UI flow around them is quite different.
  • When you click a custom scheme link you see the title and underneath an impossible to read (due to contrast) origin. You don't see the scheme that is involved except in the spoofable link tooltip. I think we should show the custom scheme involved here and the origin that will handle it for that scheme. (Again, for privileged applications we can show their non-origin title.)

I don't have a good handle on whether to show the favicon. If the origin title is emphasized somehow it is probably okay.

Flags: needinfo?(annevk)

@annevk Thanks. I'm still not clear whether this is your personal opinion or a consensus within Mozilla. Anyway, I've tried to simplified https://phabricator.services.mozilla.com/D71714 a bit, so that it only removes the title for the web-exposed part.

Pushed by rmaries@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e6dcf7fa653d
Remove the title argument from registerProtocolHandler() r=smaug
Keywords: dev-doc-needed
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch

MDN documentation completed for this one; see https://github.com/mdn/sprints/issues/3899#issuecomment-731252628 for the full details.

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