Remove the title argument from registerProtocolHandler()
Categories
(Core :: DOM: Navigation, defect, P3)
Tracking
()
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).
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
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.
Assignee | ||
Comment 4•5 years ago
|
||
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.
Comment 5•5 years ago
|
||
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.
Assignee | ||
Comment 6•5 years ago
|
||
Sorry I was not clear, here is a screenshot (Nightly is the item registered by the page).
Comment 7•5 years ago
|
||
I'm a bit puzzled about this and the spec change, when the title is used in the UI.
Comment 8•5 years ago
|
||
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.
Comment 9•5 years ago
|
||
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?
Comment 10•5 years ago
|
||
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.
Comment 11•5 years ago
|
||
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.
Updated•5 years ago
|
Assignee | ||
Comment 12•4 years ago
|
||
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.
Comment 13•4 years ago
|
||
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.
Assignee | ||
Comment 14•4 years ago
|
||
@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.
Comment 15•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Comment 16•4 years ago
|
||
bugherder |
Comment 17•4 years ago
|
||
MDN documentation completed for this one; see https://github.com/mdn/sprints/issues/3899#issuecomment-731252628 for the full details.
Description
•