Skip to content
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

Add details to the Application cache deprecation #5505

Closed

Conversation

quisquous
Copy link

@quisquous quisquous commented May 1, 2020


/index.html ( diff )
/offline.html ( diff )

@quisquous
Copy link
Author

@annevk This is per our discussion on blink-dev about Chrome experimenting with a reverse origin trial in deprecating AppCache. This description is how I was planning to implement this in Chrome (patch in flight) for any application cache that does not have a valid origin trial token in its manifest. I tried to write this in such away that it could apply to all browsers and not talk about origin trials here.

This is my first spec edit, and this also seems a little bit abnormal of an addition to a spec, so I would take any and all guidance in this pull request.

sideshowbarker
sideshowbarker previously approved these changes May 2, 2020
<!-- NON-NORMATIVE SECTION -->

<p>As this feature is being removed from the Web platform, it may go through a stage where
the back-end implementation has been disabled, but the Application cache API is still available
Copy link
Contributor

@sideshowbarker sideshowbarker May 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
the back-end implementation has been disabled, but the Application cache API is still available
browser engines have disabled or removed their underlying implementations, but are still exposing the Application cache API

…or something like that

cache</a> via a manifest attribute will result in the behavior of the
<span>cache failure steps</span>, as if the manifest had a parse error.</p>

<p>Additionally, when the back-end is disabled, the application cache should behave as if no
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p>Additionally, when the back-end is disabled, the application cache should behave as if no
<p>Additionally, when the underlying implementation has been disabled or removed, the application cache will behave as if no

The word should can’t be used in non-normative spec content.

Or if the normative requirements that mandate the behavior described here aren’t already specified elsewhere in the spec, then this “the application cache should behave as if no resources have been cached” text would need to be moved out of this non-normative part and into a normative section.

@sideshowbarker sideshowbarker self-requested a review May 2, 2020 03:30
@sideshowbarker sideshowbarker dismissed their stale review May 2, 2020 03:33

didn’t intend to approve…

@annevk
Copy link
Member

annevk commented May 4, 2020

I think this matches what Firefox will do. @valenting can confirm. I think I'd rather see if this works out in implementations and then remove all the relevant text from the standard. That is, I don't think we need to merge this, but this can serve as useful documentation until we get there.

(Removal is tracked by #151.)

@valenting
Copy link

Our upcoming deprecation event in Firefox 79 will disable the storage backing appcache - this means that the status will always return the UNCACHED state.
We do not have a timeline to remove the API yet.

@quisquous
Copy link
Author

That is, I don't think we need to merge this, but this can serve as useful documentation until we get there.

Thanks for the clarification. The important part to me is the conversation here to make sure the browser engines are behaving in similar ways during the removal process.

Our upcoming deprecation event in Firefox 79 will disable the storage backing appcache - this means that the status will always return the UNCACHED state.

Thanks for the clarification.

Chrome will go through CHECKING first, because we are conditionally allowing some manifests through our origin trial process. If we decide a manifest is not allowed, then we will go through the cache failure steps, and then also arrive at UNCACHED. I don't see any issues with this difference between the two browsers, but just wanted to mention it for the sake of being explicit.

annevk added a commit that referenced this pull request Nov 17, 2020
This removes the manifest attribute on the html element, the text/cache-manifest format, the integration of application caches with navigation, the monkey patching of what is now Fetch, and the window.applicationCache API.

Closes #151 and closes #5505.
@annevk annevk mentioned this pull request Nov 17, 2020
6 tasks
annevk added a commit that referenced this pull request Nov 30, 2020
This removes the manifest attribute on the html element, the text/cache-manifest format, the integration of application caches with navigation, the monkey patching of what is now Fetch, and the window.applicationCache API.

Closes #151 and closes #5505.
@annevk annevk closed this in #6153 Dec 1, 2020
annevk added a commit that referenced this pull request Dec 1, 2020
This removes the manifest attribute on the html element, the text/cache-manifest format, the integration of application caches with navigation, the monkey patching of what is now Fetch, and the window.applicationCache API.

Closes #151 and closes #5505.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

5 participants