Intent to unship: navigator.registerContentHandler()

[Jonathan Kingston]

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

Thanks
Jonathan

[Mike Taylor]

Hi Jonathan,

> On Jan 3, 2018, at 9:15 AM, Jonathan Kingston <j...@mozilla.com> wrote:
> 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.

I’m never confident sites are doing feature detection or handling errors… I like the approach of disabling a feature (behind a pref) in non-Release (Beta and Nightly) for a few releases, to see what surfaces in bug reports.

> - Is only implemented by Firefox

(It was also in Opera Presto 11.60+, RIP)

--
Mike Taylor
Web Compat, Mozilla

[Jonathan Kingston]

> I like the approach of disabling a feature (behind a pref) in
non-Release (Beta and Nightly) for a few releases, to see what surfaces in
bug reports.

This is reasonable, it is the approach we will be taking with the device
sensors. Obviously it takes a little more work however I'm guessing the
breakage risk will be higher than events .

As you mention, I'm going to propose that we move to implement a pref to
disable this feature instead. In Nightly and early beta enable this pref by
default and see if we have any issues.

Thanks
Jonathan

[Karl Dubost]

Jonathan,

Le 4 janv. 2018 à 00:15, Jonathan Kingston <j...@mozilla.com> a écrit :
> Firefox has an implementation that only can be used to allow a web page to
> handle RSS feeds.

in Firefox 8, the feeds panel was removed from Firefox. It created a bit of bad press.
Some people have developed add-ons to cope with the removal.
https://developer.mozilla.org/en-US/Firefox/Releases/2/Adding_feed_readers_to_Firefox

If I check https://addons.mozilla.org/en-US/firefox/search/?q=rss+reader
I can see a couple of addons for reading RSS/Atom feeds.

Do we have a way to know how many add-ons might break with this removal?


Also
https://github.com/search?utf8=%E2%9C%93&q=registerContentHandler&type=Issues


Chromium world.
Implementation https://bugs.chromium.org/p/chromium/issues/detail?id=11359
Disabled in https://bugs.chromium.org/p/chromium/issues/detail?id=44984
Discussions in https://bugs.chromium.org/p/chromium/issues/detail?id=86115

WebKit world.
Proposed https://bugs.webkit.org/show_bug.cgi?id=73177 (last activity 2014)



--
Karl Dubost, mozilla 💡 Webcompat
http://www.la-grange.net/karl/moz

[Frederik Braun]

On 04.01.2018 04:46, Karl Dubost wrote:
> Jonathan,
>
> Le 4 janv. 2018 à 00:15, Jonathan Kingston <j...@mozilla.com> a écrit :
>> Firefox has an implementation that only can be used to allow a web page to
>> handle RSS feeds.
>
> in Firefox 8, the feeds panel was removed from Firefox. It created a bit of bad press.
> Some people have developed add-ons to cope with the removal.
> https://developer.mozilla.org/en-US/Firefox/Releases/2/Adding_feed_readers_to_Firefox
>
> If I check https://addons.mozilla.org/en-US/firefox/search/?q=rss+reader
> I can see a couple of addons for reading RSS/Atom feeds.

I found 49 addons in DXR.

23 of those occurrences are irrelevant:
- uglify.js has list of known dom properties, which seem important for
mangling.
- Firefox OS simulators

[Gervase Markham]

On 03/01/18 15:15, 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.

I'm sure unshipping it is the right thing to do, but it's very sad. :-(
Allowing web pages to register for content types and protocols seems
kind of important if you want the web to have the capability of
seamlessly replacing desktop and mobile apps.

Gerv

[Anne van Kesteren]

On Tue, Jan 9, 2018 at 5:30 PM, Gervase Markham <ge...@mozilla.org> wrote:
> I'm sure unshipping it is the right thing to do, but it's very sad. :-(
> Allowing web pages to register for content types and protocols seems
> kind of important if you want the web to have the capability of
> seamlessly replacing desktop and mobile apps.

It might still be worth pursuing, but note that the current API is
rather broken and results in two loads of the content (and how it
integrated with navigation/fetching was never really defined in
sufficient detail). A better API would be handing of the stream of the
download somehow to the third-party. Also note that the "protocol" API
is still there.


--
https://annevankesteren.nl/

[L. David Baron]

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.

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.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[L. David Baron]

On Tuesday 2018-01-09 08:51 -0800, L. David Baron wrote:
> 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.
>
> 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.

Though given Anne's point about wanting an API that doesn't do two
loads of the content, I guess removal is probably the right thing.
But it would really be good to work on standardizing something
better here.

[Jonathan Kingston]

I would like to see the expansion of this feature here, especially for
handling more types of content. Chrome has been working on Web Share Target
API[1] which somewhat overlaps this behaviour and could be expanded to cope
with the use cases here. I actually think web sharing is the answer here,
it also seems like we need to go back to the drawing board for this API if
we want this anyway.

Also if there is need for web extension functionality here that could
be addressed without having to expose this to the web.

I have an r+ on the patch which disables this in Nightly and early
Beta, unless there are objections I will land this in central in a few
days and we can measure if there is any issues before filing another
removal for stable.


[1] https://github.com/WICG/web-share-target/blob/master/docs/explainer.md

[Fabrice Desre]

On 01/09/2018 04:59 PM, Jonathan Kingston wrote:
> I would like to see the expansion of this feature here, especially for
> handling more types of content. Chrome has been working on Web Share Target
> API[1] which somewhat overlaps this behaviour and could be expanded to cope
> with the use cases here. I actually think web sharing is the answer here,
> it also seems like we need to go back to the drawing board for this API if
> we want this anyway.

WebShare is more a trimmed down version of the WebActivities/WebIntents
apis. I think it's unfortunate that instead of fixing the issues with
WA/WI they went with a single purpose API - this doesn't scale at all
with uses case they don't think about and limits the innovation for
content publishers.

[rek...@gmail.com]

I really like this extension mechanism for the web. Unlike, say, registerProtocolHandler, which is relatively widely supported, registerContentHandler allows extensibility for experiencing resources on the web while still remaining on the firm earth of HTTP and the web.

If possible, I'd prefer Firefox move it to Secure Context only rather than remove it. The RSS use case alone is a good and a strong use case!

It is very very unfortunate IMO that other browsers have not implemented this capability. I would prefer changing that fact than removing the capability from Firefox. Failing that, I would prefer Firefox maintain this very longstanding, interesting and enriching capability. The ability to grow the amount of content the browser can help the user navigate is an important capability, and nothing else does the job at all like registerContentHandler(). Ty.

[Tantek Çelik]

> 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

[Tantek Çelik]

On Wed, Jan 10, 2018 at 2:19 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

> On Wed, Jan 10, 2018 at 2:06 AM, Fabrice Desre <fab...@desre.org> wrote:
>> WebShare is more a trimmed down version of the WebActivities/WebIntents
>> apis. I think it's unfortunate that instead of fixing the issues with WA/WI
>> they went with a single purpose API - this doesn't scale at all with uses
>> case they don't think about and limits the innovation for content
>> publishers.
>

> It's a little off-topic, but the overall issue with both of those
> technologies was that the approach was too general. And such overly
> generic APIs do not translate to good UX. I think starting small and
> slowly expanding the types of things we want to make extensible, and
> thinking those through all the way up to and including the user
> experience, makes for a much more viable approach.

You're both right.

WA/WI were both way-over-architected*, however with WebShare, it's
overcorrecting the other direction, it's an API that may be too
limited, and in particular limited in such a way that unnecessarily
(and badly) biases large anti-privacy (among other ills) vertical
content silos.

While I generally agree with Anne's philosophy "starting small and
slowly expanding the types of things we want to make extensible", I
think the "which small" needs to be evaluated by a frank "Is this
actually *good* for the open web, neutral, or actively bad?"
(unfortunately the latter in this case).

Also good methodology worth repeating:
"thinking ... through all the way up to and including the user
experience, makes for a much more viable approach"

Finally Anne is right about it being a little off-topic. This github
issue may be a better place for WebShare follow-ups (more specifics
there): https://github.com/mozilla/standards-positions/issues/27

Thanks,

Tantek

*https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/

[Daniel Veditz]

On Wed, Jan 10, 2018 at 5:35 PM, Tantek Çelik <tan...@cs.stanford.edu>
wrote:

> Also good methodology worth repeating:
> "thinking ... through all the way up to and including the user
> ​​
> experience, makes for a much more viable approach"
>

​Including, of course, "how will 4chan trolls abuse this?" and "how will
ad-tech trackers abuse this?"​

-Dan Veditz

[Tantek Çelik]

Why stop there?

What about "how will state-level-actors abuse this to mislead,
surveil, and censor users?" (only 1/2 :)

While I agree with asking the sorts of questions you're asking, I
think such abuse-cases are a distinctly different class of design
problems/considerations than what I believe was a positive UX design
methodology that Anne expressed, of making sure users can actually
viably get done what they want to get done.

That being said, perhaps consider filing issues to add your questions
to the W3C Security & Privacy questionnaire, especially if you think
we should be asking them for every web standards spec/API/feature we
consider contributing to and /or implementing.

https://github.com/w3ctag/security-questionnaire

Thanks,

Tantek