Closed domfarolino closed 1 year ago
It used to queue a task because it got the state from elsewhere. We could consider dropping it, but it would be an observable change. And it would make it impossible to obtain the state in parallel at a later point if we decided that was necessary for some reason.
Makes sense, thanks. It would indeed be observable, do you know what implementations do? I have a hard time believe they actually queue a task here if they are no longer getting the data from in parallel. Blink doesn't seem to: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/document.cc;l=6084;drc=ab54f91b250236cf874aa0935908a9242ece18da. I guess a test for this would be good anyways.
Well, I'm glad you asked: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/11267.
Seems like no implementations queues a task.
So we can just remove that? :)
Yeah (and add a simple test).
Just FYI, issue https://github.com/privacycg/storage-access/issues/171 suggests having document.hasStorageAccess
check the state of unpartitioned cookie access for the current context. If that change will be made, will that affect the decision here?
Blink currently does not queue a task to get unpartitioned cookie access state https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:services/network/public/mojom/restricted_cookie_manager.mojom;l=135-140;drc=b8a0323a84f483b25e94b3a24d80fda16c5dd1ae;bpv=0;bpt=1 But it should not be difficult to change that.
Yeah, I think this should be WONTFIX as you suggested in that issue.
Thanks for pointing this out @shuranhuang
In step 9 of https://privacycg.github.io/storage-access/#dom-document-hasstorageaccess, we seem to always queue a task to resolve the promise (returned in step 10) with global's has storage access. Why don't we just resolve it right then and there, is there a reason to unconditionally post a task?