-
Notifications
You must be signed in to change notification settings - Fork 351
Changing skip-service-worker flag to use-service-workers enum #435
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Technically, this and skip-service-worker could become an enum of "none", "local" and "all", but it feels like that'd break specs already using it. Is that the right thing to do? |
Related SW PR w3c/ServiceWorker#1025 |
I think I prefer the enum approach. There's not too many consumers as far as I know. |
Cool, I'll update the PR |
Thanks. There's also #362 which relates to this flag somewhat. |
fetch.bs
Outdated
|
||
<p>A <a for=/>request</a> has an associated <dfn export>skip-local-service-worker flag</dfn>. Unless | ||
stated otherwise it is unset. | ||
<dfn export>use-service-workers value</dfn>, that is "<code>all</code>", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs for=request
too. Seems we forgot that until now.
So where do we check for the |
Do we have WPT tests around this? |
Yeah, when it comes to performing foreign fetch we're only really concerned that the value isn't "none". Although I'm not sure what else could be reused.
No, I guess this is something I should learn and do 😄 |
And it cannot be "all" either I guess? I guess "foreign" is fine then. Can @mkruisselbrink have a look or is he still away? |
As for the tests, the new rule is that they land together with the specification change. Let me know if you need help. |
And only https://w3c.github.io/ServiceWorker/ seems to use the skip-service-worker flag currently. We should maybe prepare a PR there too so they can all land at the same time. |
fetch.bs
Outdated
@@ -728,8 +728,9 @@ explicitly set <a for=/>request</a>'s | |||
this flag set are subject to additional processing requirements. | |||
|
|||
<p>A <a for=/>request</a> has an associated | |||
<dfn export>skip-service-worker flag</dfn>. Unless stated otherwise it is | |||
unset. | |||
<dfn export>use-service-workers value</dfn>, that is "<code>all</code>", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about <dfn export for=request>service-workers mode</dfn>
? I think that would be more consistent with what we have thus far.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM, I wasn't happy with the naming
fetch.bs
Outdated
@@ -2793,16 +2794,14 @@ optional <i>CORS flag</i> and <i>CORS-preflight flag</i>, run these steps: | |||
<li><p>Let <var>actualResponse</var> be null. | |||
|
|||
<li> | |||
<p>If <var>request</var>'s <a>skip-service-worker flag</a> is unset, then run these | |||
<p>If <var>request</var>'s <a>service-workers mode</a> is not "<code>none</code>", then run these | |||
substeps: | |||
|
|||
<ol> | |||
<li> | |||
<p>If <var>request</var>'s <a for=request>client</a> is null or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need the client is null check, or is just relying on the service-workers mode enough now? And in particular it seems wrong that service-workers mode==foreign and client==null will now result in handle fetch being called.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that relying on service-workers mode is enough. At least, I thought the idea was that having a client no longer mattered.
@@ -728,8 +728,9 @@ explicitly set <a for=/>request</a>'s | |||
this flag set are subject to additional processing requirements. | |||
|
|||
<p>A <a for=/>request</a> has an associated | |||
<dfn export>skip-service-worker flag</dfn>. Unless stated otherwise it is | |||
unset. | |||
<dfn for=request export>service-workers mode</dfn>, that is "<code>all</code>", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to add some non-normative text somewhere to explain what this mode actually means? Of course you can figure that out by reading the algorithms, but I find the non-normative notes that many of the requests attributes have to be quite helpful in quickly figuring out what a particular thing is for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, sounds good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Hmm, I should probably also work on actually upstreaming the existing foreign fetch tests we have in blink. Although not sure what WPT tests would be desired for this specific change, as this change by itself doesn't seem to have any behavioral changes? |
The fact that certain fetches from the service worker can now invoke the service worker is a normative change that will result in behavioral changes. |
I agree this is a change that needs tests. Will pick this up after the Christmas break. |
Tests: jakearchibald/web-platform-tests@0fa7353 @annevk would be grateful for a review. Be kind! |
@jakearchibald probably best to create a PR on web-platform-tests for review. Overall I think it's fine, but since you need permissions you'll have to use the -manual suffix I think. |
7d2c1b5
to
835862f
Compare
@annevk tests merged. Happy to merge this? |
fetch.bs
Outdated
"<code>all</code>". | ||
|
||
<div class=note> | ||
This determines which service workers will receive a {{fetch!!event}} event for this fetch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should start with a <p>
.
One more question, in a commit you stated #362 is fixed by this, but that seems unlikely as service workers are skipped for redirects with this change. So are we leaving that for that issue? Could you write a commit message for this? |
@annevk uhhhh good catch. Sorry about that. As far as I can tell it just needed that "none" changed to "foreign". |
Commit message:
|
Thanks! (Adjusted the message a bit to fit style guidelines.) |
This was changed in the following PR to the Fetch standard: whatwg/fetch#435 BUG=592188 Review-Url: https://codereview.chromium.org/2714423002 Cr-Commit-Position: refs/heads/master@{#453432}
Introduce service-worker mode Bringing in the spec changes from whatwg/fetch#435. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17491) <!-- Reviewable:end -->
Introduce service-worker mode Bringing in the spec changes from whatwg/fetch#435. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17491) <!-- Reviewable:end -->
…date-fetch); r=jdm Bringing in the spec changes from whatwg/fetch#435. Source-Repo: https://github.com/servo/servo Source-Revision: e2a26e7bd0d8089a441bc3072cf15351b0ef1252 --HG-- extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear extra : subtree_revision : 05549195b43020dcd02768bcd79cef5f7ed4b813
…date-fetch); r=jdm Bringing in the spec changes from whatwg/fetch#435. Source-Repo: https://github.com/servo/servo Source-Revision: e2a26e7bd0d8089a441bc3072cf15351b0ef1252
…date-fetch); r=jdm Bringing in the spec changes from whatwg/fetch#435. Source-Repo: https://github.com/servo/servo Source-Revision: e2a26e7bd0d8089a441bc3072cf15351b0ef1252
…date-fetch); r=jdm Bringing in the spec changes from whatwg/fetch#435. Source-Repo: https://github.com/servo/servo Source-Revision: e2a26e7bd0d8089a441bc3072cf15351b0ef1252
…date-fetch); r=jdm Bringing in the spec changes from whatwg/fetch#435. Source-Repo: https://github.com/servo/servo Source-Revision: e2a26e7bd0d8089a441bc3072cf15351b0ef1252 UltraBlame original commit: 7ad2e4b94b03bb9e821f6962fc7df6fc0f936519
…date-fetch); r=jdm Bringing in the spec changes from whatwg/fetch#435. Source-Repo: https://github.com/servo/servo Source-Revision: e2a26e7bd0d8089a441bc3072cf15351b0ef1252 UltraBlame original commit: 7ad2e4b94b03bb9e821f6962fc7df6fc0f936519
…date-fetch); r=jdm Bringing in the spec changes from whatwg/fetch#435. Source-Repo: https://github.com/servo/servo Source-Revision: e2a26e7bd0d8089a441bc3072cf15351b0ef1252 UltraBlame original commit: 7ad2e4b94b03bb9e821f6962fc7df6fc0f936519
…date-fetch); r=jdm Bringing in the spec changes from whatwg/fetch#435. Source-Repo: https://github.com/servo/servo Source-Revision: e2a26e7bd0d8089a441bc3072cf15351b0ef1252
This fixes #303. I don't think there's anything else to do with this PR, but I need to make changes to SW to set this flag on particular APIs.