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

allow disabled-by-default features #513

Open
fergald opened this issue May 19, 2023 · 5 comments · May be fixed by #515
Open

allow disabled-by-default features #513

fergald opened this issue May 19, 2023 · 5 comments · May be fixed by #515

Comments

@fergald
Copy link
Contributor

fergald commented May 19, 2023

Motivation:

This would be a tool to use in deprecating and removing a feature. Our current motivator for this is the deprecation of unload but it could apply to any other feature.

Deprecating is hard and we want to provide a period where a feature is still usable but opt-in. The plan for unload is more complicated than just flipping to this state but this is the desired state.

Currently the available defaults for a feature are self and *. It is not possible to have a policy that disables a feature by default.

Proposal

Add an allowed default value of none. This would mean that by default, the feature is not available. To make the feature available in a given frame, that frame would have to declare it via the header and every ancestor of that frame would also have to declare it via the header and delegate it via the allow attribute on the iframe element.

This

  • fits with the existing PP model
  • achieve goal of allowing opt-back-in
  • opt-in requires action on by allow frames in the ancestry chain

The unfortunate side-effect of forcing the feature to be enabled in a the ancestor frames even if they do not want it could be avoided by also implementing not-self .

Alternative outcomes

There are some different outcomes one could imaging trying to achieve.

require action only by the subframe itself

  • by subframes can enable feature
  • ancestors can epxlicitly prevent this

This would make it easier to opt back in while still giving containers utlimate control. It does not seem to sit with the existing inheritance model of PP and would require changes to the decision algorithm, not just the available defaults.

require action only by the containing frames

  • subframes don't need to explicitly enable the feature
  • ancestors enable the feature

This would allow sites to restore unload functionality to 3rd party frames even without the cooperation of the 3rd party. It seems like 3rd parties have an incentive to enable the features they use, so this is of questionable benefit vs the proposed outcome.

@clelland

@fergald fergald linked a pull request May 26, 2023 that will close this issue
@clelland
Copy link
Collaborator

One issue that might motivate the second alternative (besides it just being onerous to have to enable by attribute and header at every frame boundary) is that some contexts actually don't allow for headers to be set -- <iframe srcdoc> , for instance, only allows the content of the frame to be set, not the headers.

I wonder if it would actually be so bad to have a model where:

  • The feature is disabled by default at the top-level
  • The top-level document can enable it by a header
  • The feature does not propagate into any child frames, unless allowed by an allow attribute
  • The header is not necessary in the child frames (unless they want to block the feature)

@marcoscaceres

@fergald
Copy link
Contributor Author

fergald commented May 30, 2023

Does it make sense to say that a srcdoc has the same header policy as its parent? Does that change any previous behaviour?

@fergald
Copy link
Contributor Author

fergald commented Jun 14, 2023

@smaug--- is there anyone from Mozilla who can weigh in on this?

@marcoscaceres Ian mentioned you had an idea for different semantics.

@fergald
Copy link
Contributor Author

fergald commented Jun 15, 2023

@smaug---- is there anyone from Mozilla who can weigh in on this?

@annevk
Copy link
Member

annevk commented Jun 16, 2023

Is there another feature for which this would make sense? As per WebKit/standards-positions#200 WebKit is not sold on unload. There was an idea before for document.domain, but the scoping ended up being wrong and eventually we landed on something better.

It also seems somewhat unfortunate to introduce new features in order to potentially remove another one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants