Not all deprecations are seen by a ReportingObserver |
|||||
Issue descriptionChrome Version: 69.0.3496.0 (Official Build) canary (64-bit) OS: macosx What steps will reproduce the problem? (1) goto https://www.cnn.com/ (2) See several deprecations in the console. (3) Run the following code on the page: (new ReportingObserver((reports, observer) => { for (const report of reports) { console.log(`[${report.type}]`, report.body, report.url); } }, {types: ['deprecation'], buffered: true})).observe(); What is the expected result? The two deprecations shown in the console are reported by the API. What happens instead? Nothing is observed.
,
Jul 24
Given deprecation reports are shipping M69, ideally this would be fixed and merged back (or at least root cause identified).
,
Jul 26
Bumping the priority. Ideally would be addressed for Beta promotion, which is Aug 2.
,
Jul 30
,
Aug 1
Has anyone been able to repro this bug on any other site? When testing on cnn.com, shortly after loading, the page seems to slow down DevTools to a halt, and then I can't execute any commands anymore.
,
Aug 1
Actually, I've figured it out. The reason the reports are not being seen is because the deprecations are occurring in a different frame than the main frame. In the repro steps of this bug, the observer is being registered on the main frame, but the deprecations are coming from a subframe. Currently, ReportingObservers can only observe reports generated in the same frame as they are registered. So, technically this is currently working as intended. The question of whether ReportingObservers SHOULD be able to get reports from subframes is potentially still an open question.
,
Aug 1
Oh interesting. Thanks for tracking that down. Perhaps this is more of a disconnect with DevTools warnings then. They report subframe violations but a RO on the main frame would not. Or maybe there's a `subframe: true` option that RO could support?
,
Aug 1
I think we should make it easy (or at least possible) for developers to collect reports across frames. At least for same-origin frames. This is discussed in the context of reporting for Feature Policy: https://github.com/WICG/feature-policy/blob/master/reporting.md#what-about-the-frames-i-embed-can-i-get-reports-for-those-too
,
Aug 1
I originally designed ReportingObserver in a way that reports would propagate up same-origin frames, so that an observer in the main frame could observe all same-origin frames. It wasn't terribly popular during design discussions though, and it was pointed out by numerous people that this didn't actually provide additional functionality, as a dev could just register a different ReportingObserver in every frame (using the same callback) to accomplish the same behavior. That being said, I still support this kind of functionality as a convenience / quality of life improvement. I also really like the idea of using an option for it. It could default to false and work the same as now, but if you want to just make one observer and get your whole page observed for free, then you can do that too. I'd be happy to get the spec changes in and implement this new option (actually I already figured out a good way to do this and had it implemented in my original prototype, so I should be able to just revive that code), though it will likely fall lower in priority than getting more report types shipped first (crashes for sure, maybe some of the others like performance warnings and JS errors that have been suggested more recently). |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ericbidelman@chromium.org
, Jul 19133 KB
133 KB View Download