Add "has storage access" boolean to environment#10990
Add "has storage access" boolean to environment#10990bvandersloot-mozilla wants to merge 4 commits intowhatwg:mainfrom
Conversation
|
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. |
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. |
|
Ah cool, that sounds great! I'm glad to hear the plan is to land everything at once. I don't have an opinion on 1 PR vs. 3. |
|
+1 on that this is also my understanding :) |
|
I rebased this and addressed the formatting concerns. I also updated Domenic's comment above to point to a replacement PR for the one that was not maintained. |
|
What is the status of this PR? There are a few open comment threads and it's not clear if they're resolved yet or not. |
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.
23d5d32 to
f6f0af2
Compare
Looks like it inadvertently got ignored after TPAC. I've adopted our changes from those threads and pending the rewording, it should be good. Though we will need tests for storage access API for the scenarios you outlined in the thread where we moved it to the policy container. |
|
This is looking good, and I feel like it's LGTM-able, with the exception of:
Basically it's not clear how web-observable this is to me. If new tests are needed, then clearly it is and we need browser support. If not (and no tests are needed / there are no testing implications), then I guess we don't, because it's basically editorial. |
Chrome's implementation has the boolean in the environment, rather than in policy container, but I think putting in policy container would help with the plan in privacycg/storage-access#157 for dedicated workers (which I haven't had time to spec out). So Chrome's implementation doesn't support this yet, but Chrome is supportive of this change overall.
I think the original PR description was correct that the placement in environment was already covered by WPTs (so this PR was editorial), but now that it's placed in policy container instead, we'll need additional WPTs. (Re: "you", I think bvandersloot meant Domenic since he was the one who suggested policy container.) |
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 )