Html: Using "report an error" for deprecation warnings?

[RByers]

Is it reasonable (and likely to be web compatible) to use the report an error steps for scenarios other than those currently defined by HTML?

In particular, I think the web desperately needs an API to report that the application is relying on an API (or pattern) that is going to break in a future version of the UA. Is this the sort of thing that would be worth discussing extending window.onerror for (perhaps with a new type for the value to reliably identify it as a deprecation warning)? Or should I propose an entirely new API for this instead?

[domenic]

Interesting question!

The biggest thing to consider, I think, is: should it be sent to their same in-the-field error telemetry tools that currently monitor window.onerror on many web sites? I'm not sure myself.

How to identify the issue is another interesting one. Maybe a new DOMException name.

[RByers]

The biggest thing to consider, I think, is: should it be sent to their same in-the-field error telemetry tools that currently monitor window.onerror on many web sites? I'm not sure myself.

Exactly. If we restrict this to things that will definitely fail (eg. throw) in the future then I think the answer is probably yes. It's less clear for things which may fail in a way that tends to be more silent (eg. geolocation prompts being auto-denied).

I guess even the common case of API removal is tricky. Code that enumerates properties can trigger the deprecation warning even though the removal isn't likely to break anything (eg. this is common for properties on Event for example). But libraries have already established a pattern of skipping known deprecated properties in such cases to prevent console spam, so perhaps triggering onerror is no worse really?

[RByers]

I know the answer: web API design via Twitter poll!

[patrickkettner]

I am literally writing a spec around this idea right now, actually.

The elevator pitch is to replicate CSP report-only style reporting (e.g. a meta tag/http header that specifys an endpoint, and possible configuration syntax), but for arbitrary messages sent from the browser to developers. With this, browsers would be able to send messages about deprecated APIs, devs could opt into audits where the browser sends the results of it back from real world users through it, etc.

cc @gregwhitworth

[RByers]

Thanks Patrick! That was my original idea too, and certainly most flexible. Would love to collaborate on that (WICG?)

But getting all the telemetry providers to opt-in would take awhile. So doing this as well could have immediate benefit (and be really simple, something I could see shipping this quarter). Also Facebook has told us they prefer JS so they can use their own telemetry channel to keep all session data correlated easily.

[RByers]

@patrickkettner, note the CSP report mechanism is already being separately specified: http://wicg.github.io/reporting/

[RByers]

It sounds like there's more support for using just the Reporting API here and not messing with onerror. Let's continue the discussion at https://github.com/WICG/reporting/issues/27.