On Tue, Jan 9, 2018 at 8:51 AM, L. David Baron <[email protected]> wrote: > On Wednesday 2018-01-03 15:15 +0000, Jonathan Kingston wrote: >> I am suggesting the removal of navigator.registerContentHandler >> <https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerContentHandler> >> API used to register a web page to handle content types. >> >> Firefox has an implementation that only can be used to allow a web page to >> handle RSS feeds. We don't have telemetry on this feature however we do >> know that registerProtocolHandler has around 0.2% usage and this feature is >> implemented in multiple browsers and isn't specific to Firefox. >> >> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1398169 >> >> There is a small risk of breakage that we could decide to delay and instead >> implement telemetry. However if the site is feature testing rather than >> user agent testing there shouldn't be an issue here. As this API throws >> errors there is likelihood websites account for it throwing anyway. I would >> prefer however to let the removal ride the trains due to it's low risk >> before 61 so our ESR doesn't have it. >> >> Alternatively we could restrict this API to Secure Context only due to the >> risk of passing web content to an insecure context. This would be aligned >> with our overall plan regarding HTTP APIs. >> >> Removal of this feature requires the removal of some internal tests and to >> stop ignoring a web platform test. >> >> The rationale: >> >> - This API had bugs filed on it's implementation >> - Is only implemented by Firefox >> - The API is now non standard >> - No other browsers have intent to implement > > I'm a little hesitant here -- this is an important feature for > allowing Web apps to fulfil the function that desktop apps do, and > I'd rather push to see it expand. > > For example, if we added support for registering for text/calendar, > then Google Calendar could choose to register for that, and thus > become the handler for random ICS files that I'm served by sites > that allow me to make appointments.
Agreed. There has also been a bit of a resurgence in Web (feed) reader development in the past two years (picked up since Google Reader shutdown), many (most?) open source at that. E.g. https://woodwind.xyz/ Additional examples here: https://indieweb.org/feed_reader Were these readers to implement registerContentHandler to register for the Atom & RSS content types, it would turn the zillions of little orange [XML] links/buttons on websites into decentralized opt-in "Follow" buttons for the web, without having to change existing publishers. However: I don't know if any of these new readers support registerContentHandler today (or why they would not have already, whether not knowing about it, or due to being Firefox only). I am investigating into these readers and will follow-up. > Right now desktop calendar apps have more power than web calendar > apps do here, for no good reason, and it seems like we ought to be > trying to change that. Agreed, same with desktop addressbooks, text/directory, vCard, web based address books, etc. The problems with registerContentHandler noted in this thread seem fixable, especially we're the only remaining (live) implementation, so not reason enough to deprecate / remove per se. Tantek _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
