search

w3c / resource-timing

Resource Timing
https://w3c.github.io/resource-timing/
Other
122 stars 37 forks source link

Be a bit more explicit about which subresources are to be ignored from stylesheets #200

Closed npm1 closed 3 years ago

npm1 commented 5 years ago

The spec currently says "If the resource is fetched by a cross-origin stylesheet which was fetched with no-cors policy, abort the remaining steps." This seems to mean that all subresources from such stylesheet should be ignored. But the current wording could be interpreted as only direct fetches from the stylesheet. For example, consider this fetch chain: stylesheet A -> stylesheet B -> resource C In this case, when A is no-cors cross-origin, I believe C's RT information should not be exposed, and we should make this clear.

yoavweiss commented 5 years ago

Concluded on the call: even if B and C are same-origin, they should not be exposed

toddreifsteck commented 5 years ago

Per W3C call on 8/1, we need to add tests and spec language to ensure browsers are able to implement properly.

yoavweiss commented 5 years ago

I just spent some time thinking of a language that would allow us to hand wavily define this without saying "dependency trees" which are a big and loaded term...

Ideas welcome! :)

yoavweiss commented 3 years ago

/cc @annevk @noamr

Anne - I'd appreciate ideas on how we can know in Fetch that a resource was fetched by no-cors CSS

@jakearchibald @wanderview - Thoughts? Did y'all define this for SWs?

mfalken commented 3 years ago

This is still tracked here https://github.com/w3c/ServiceWorker/issues/719 for SW and we haven't defined it.

annevk commented 3 years ago

Cross-origin no-cors CSS, right? CSS could set request's service-workers mode to "none" for such requests. I suppose it could also set request's timing allow failed flag and things would work out, but we might want to make it a bit clearer that's a flag a user of fetch could set as currently it's described as an internal detail.

yoavweiss commented 3 years ago

Cross-origin no-cors CSS, right?

Indeed!

I suppose it could also set request's timing allow failed flag

I don't think that's sufficient, as we want those URLs to not be reported at all, while TAO would just reduce the information they expose. Sounds like we need a separate flag for "this was fetched by a cross-origin no-cors CSS", which CSS should then set. Does that make sense?

annevk commented 3 years ago

Good point, yeah, either that or we turn the timings thing into a tri-state. It strikes me that what @noamr is adding to Fetch doesn't allow for not reporting at the moment.

yoavweiss commented 3 years ago

If we had such a flag, that's something that we could include, and avoid queueing an entry in those cases. A "triggered from CSS" flag is also something that would've been useful for the current initiatorType definition (where BG images and fonts report "css"), although that's something I'd love to deprecate and remove at some point, and replace with actual initiator info..

noamr commented 3 years ago

Note: Currently CSS @import processing is defined only in prose. I believe it needs to be define in terms of fetch or refer back to the HTML link processing before resource-timing issues can be addressed.

noamr commented 3 years ago

Depends on https://github.com/w3c/csswg-drafts/issues/562

noamr commented 3 years ago

Should be fixed by https://github.com/w3c/csswg-drafts/pull/6715

noamr commented 3 years ago

Closing now that https://github.com/w3c/csswg-drafts/pull/6715 is merged.