Add "has storage access" boolean to environment #10990
Conversation
This is a concept that originated in the Storage Access API, where it has been stuck because of spec issues between Fetch and 6265bis. To un-logjam this, I've started whatwg/fetch#1807. That depends on this bit existing. This patch adds the bit, which remains false, and does nothing.
|
To clarify, is this change integrating https://privacycg.github.io/storage-access/#ua-state into HTML? cc @cfredric If so, that seems fine by me, but I wonder if it should be part of a larger port of the storage access API (🍾 ?) |
|
@domenic would you be okay with this as an incremental step? |
|
Different Dom(e|i)nic here, but I'm curious about the "browser support". You marked all browsers as supportive in whatwg/fetch#1807, and I can't really imagine a browser being supportive of that overall effort but objecting on this PR's supplementary bit. I guess my general question is: are all browsers supportive of what exists in https://privacycg.github.io/storage-access/ (https://privacycg.github.io/storage-access/#ua-state specifically)? Second, should we expect another PR similar to this one to upstream the same bit for "source snapshot params"? What are the plans for that?
This is true from the perspective of the universe of WHATWG standards. But it'd be good to clarify in the commit message/OP that the purpose of this PR is to expose something that will be manipulated and set to true from other specifications, and just needs to appear here so that Fetch can reference it directly. |
|
All browsers are supportive. And yes, there would be further PRs to upstream the remainder of Storage Access. Pretty much all of Storage Access will end up in HTML. Good point on being super clear in the commit message. |
| @@ -107188,6 +107188,11 @@ new PaymentRequest(…); // Allowed to use | |||
| for="environment">execution ready flag</dfn></dt> | |||
| <dd><p>A flag that indicates whether the environment setup is done. It is initially | |||
| unset.</p></dd> | |||
|
|
|||
| <dt>A <dfn data-x="concept-environment-has-storage-access" export | |||
| for="environment">has storage access</dfn></dt> | |||
There was a problem hiding this comment.
The indenting of this line and the following two is too deep.
Got it. In that case, I am at least supportive of this. |
|
I'm a little unclear why this is being done in small pieces, and I worry that we'll get stuck halfway. And that the status quo will be confusing during the transition period. But, I'm happy to delegate this to other editors who are more involved in the storage access work. |
|
To be concrete about why I'm scared we might get stuck halfway:
Again, I'm happy to delegate this, but I just want to voice this concern. The alternative model would be having synchronized PRs ready across HTML, Fetch, and Storage Access API, all landable within the same day, with the Storage Access API PRs being removal PRs that remove anything that's now redundant with HTML + Fetch. |
|
To be clear, I think we should not land this before the other two HTML PRs are ready or the Fetch PR is ready to land. I think those together form an incremental step to a better cookie understanding. Landing each in isolation would be wrong. Potentially we could combine those three HTML PRs into one. Not sure what @bvandersloot-mozilla thinks about that. |
I agree with this entirely. Sorry if that wasn't clear @domenic.
I'm okay combining all of the HTML PRs into one if it helps with clarity. I had them all separate to make them easier on the Editors to reason about in isolation. Your wish is my rebase, just say the word. |
This is a concept that originated in the Storage Access API, where it has been stuck because of spec issues between Fetch and 6265bis. To un-logjam this, I've started whatwg/fetch#1807. That depends on this bit existing.
This patch adds the bit, which remains false, and does nothing.
(See WHATWG Working Mode: Changes for more details.)
/webappapis.html ( diff )