Intent to Ship: ReportingObserver, Deprecation Reports

[Paul Meyer]

Contact emails

paul...@example.com, rby...@example.com

Explainer

https://github.com/WICG/reporting/blob/master/EXPLAINER.md#basic-report-formats

Spec

https://wicg.github.io/reporting/

Tag Review

https://github.com/w3ctag/design-reviews/issues/195

Summary

These features are closely related to the previously proposed Reporting API. ReportingObserver is a new observer that will allow developers to observe reports from JavaScript (an alternative method of receiving reports from Reporting API). Deprecation reports are one type of report, to be observed by ReportingObserver and to be routed to the Reporting API backend.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/B1oztuLlzxg

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Risks

Interoperability and Compatibility

No change in existing behavior so compatibility risk should be very low.  For interoperability risk, we've been discussing the design primarily with pat...@microsoft.com on the Edge team, who is supportive.

Edge: Public support

Firefox: No signals

Safari: No signals

Web developers: We've got positive feedback from web developers at Facebook and Akamai, and are talking with Google web teams who want to use this too.

Ergonomics

This will not be used in tandem with other platform APIs for now, but will run somewhat parallel to Reporting API once that ships. It will not affect Chrome’s performance.

Activation

This feature should be immediately useful and usable, as-is. It should not require additional libraries or polyfills to be useful, though developers could easily build infrastructure of their own on top of ReportingObserver callbacks in order to track/detect (for now only) the use of deprecated features.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

This feature is currently not testable via web platform tests since there is no general way to create reports for testing. Here is an open pull request to the Reporting spec to enable generic report generation via a WebDriver extension command: https://github.com/WICG/reporting/pull/89

Entry on the feature dashboard

https://www.chromestatus.com/feature/4691191559880704

[Philip Jägenstedt]

The API owners met today to discuss this. (Alex, Daniel, Chris, Jochen, Rick, Yoav, me)

This should make our lives easier with breaking changes, making it easier for web developers to notice upcoming breakage.

Paul, the only thing that seems possibly outstanding here is the testing story. I know you've worked with +Jonathon Kereliuk and I see that https://github.com/WICG/reporting/pull/89 was closed just two days ago. What is the remaining effort required to make these tests work end-to-end in web-platform-tests? If it's only a few days work then does it make sense to block shipping on that? (If it's more, let's discuss.)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGa%2B4oj82gr6uc%2B%3DTcoOG_mmRQ8NB%3D%2BBbYDzvscky54boEesjg%40mail.gmail.com.

[Paul Meyer]

Most of the testing work is still to come. The spec for the WebDriver extension command is there, but that command on ChromeDriver still needs to be implemented, as well as a DevTools protocol for it to access (this is the only way for it to actually get at the report generation code). Once that infrastructure is in place, the web platform tests can be written using it.

I would prefer not to block shipment on this, since these features are already tested in Chrome via layout tests for now. The web platform tests will follow when they're ready!

[Philip Jägenstedt]

That's fair enough, sounds like there's a bit of work to be done, and until this path is well trodden blocking on testdriver.js additions is a bit much. Can you file/assign an issue for the remaining work, in whichever repo you think makes most sense?

I see that https://github.com/w3ctag/design-reviews/issues/195 had some action in September, but that issues #50 through #55 are all still open. One among them has the "breaking-change" label, and #72 does too. Are these issues that should be resolved before shipping?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b20b4954-d4ce-4e8a-b5da-7c92bec6b3f1%40chromium.org.

[Paul Meyer]

Okay, I will open an issue to track the remaining testing work.

As for the open issues on Reporting repo:

#50: Discusses routing report through service worker, but also supports the ReportingObserver path.

#51-#54: Not relevant to these features (pertains only to Reporting API, not ReportingObserver).

#55: About crash IDs, which is not relevant for deprecation reports.

#72: Relevant, but work completed. I will close the issue now.

So, none of these issues are blocking for these features.

[Philip Jägenstedt]

Thanks for checking in on those issues, Paul!

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/127e0c80-7872-4523-8f38-793c300aa835%40chromium.org.

[Yoav Weiss]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfBWm%2BguEE7dNCEz0vGbiQpWf7n2NjKePZjAHnXRKimEw%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhZiKkrGhTnNkE06hBwG6jEhUpkj6dSPg6YP-feUTf5EQ%40mail.gmail.com.

[PhistucK]

Regarding the testing story - what about adding an API that creates a report to the web platform itself?

Then it could be a general reporting API and not only for browser messages/web features. Like user timing and performance observers -

var observer = new PerformanceObserver((list, observer) => console.log(list.getEntries())); 

observer.observe({entryTypes: ["mark"]});

performance.mark("hello"); // the observer logs this as well

​

Deprecations also exist in code of web developers, especially when using third party libraries. They can benefit from a single place to collect all of them.

​

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8mq22qDZrDofOEvyGz3dHkJhE%3DR-_-RY%3DvsQjd91xR9A%40mail.gmail.com.

[Paul Meyer]

I had originally imagined (and proposed) using an actual new eb platform API for this, allowing custom reports to be generated:

https://github.com/w3c/reporting/issues/71

https://github.com/w3c/reporting/issues/73

It didn't meet much favor however, and there seemed to be a fairly solid consensus that a WebDriver Extension function was the way to go.

[block.rxc...@gmail.com]

Hi all

I'm trying ReportingObserver like below.

```

if (window.ReportingObserver) {

  (new ReportingObserver((reports, observer) => {

    reports.forEach((report) => {

      navigator.sendBeacon("https://example.com/reporting", JSON.stringify(report))

    })

    console.log(reports)

  })).observe()

}

```

but `JSON.stringify(report)` only results in `{}`.

why not Report interface JSON serializable ?

should I grab all properties from spec based on `type`  ?

thanks

Jxck

2018年7月6日金曜日 3時43分41秒 UTC+9 Paul Meyer: