There are some ongoing changes which might make this work for Document in https://chromium-review.googlesource.com/c/chromium/src/+/975184

Steve, now there's a good API when you have access to a Document within a renderer. Are there cases in renderers when we don't have access to it?

Otherwise I think this bug could be closed?

I think the main issue point where it is still difficult is if you are outside blink, and have a WebFrame/WebDocument object, I don't think you can get the ID from the Document because you can't traverse WebDocument->Document.

https://codesearch.chromium.org/chromium/src/third_party/blink/public/web/web_document.h?rcl=135f2e132bb84ac5d78f2c782dbcd4d9e3beba97&l=141

There might be some other way of getting around that though. Of current metrics, I think only cc/trees/ukm_manager.cc is impacted by that.

khushalsagar, I don't know much about renderer internals. Do  you have any suggestions for us?

We definitely can't access a Document or RenderFrame (main thread objects) on the cc thread. But IIUC the bug is about avoiding different places in the renderer registering their own IDs and instead using a shared source id?

If so, I think that should be easy to do. cc is currently notified of the current URL which it uses to generate a source id and tag all its events with. We can plumb a shared source id instead and use that directly in cc. We currently set the URL here (https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?sq=package:chromium&g=0&l=4340) but I think it should instead be possible to plumb the shared id which is being generated in the Document here instead (https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/document.cc?q=%22ukm_binding-%3ESetDocumentSourceId(ukm_source_id_);%22&sq=package:chromium&g=0&l=3565)