29061 2015-08-18 13:39:06 +0000 iframe@sandbox support should be feature-detectable. 2016-01-24 06:06:47 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED https://html.spec.whatwg.org/#dom-iframe-sandbox P3 normal Unsorted 28796 1 contributor ian annevk d igrigorik mike mkwst Ms2ger yoav zcorpan contributor oldest_to_newest 122640 0 contributor 2015-08-18 13:39:06 +0000 Specification: https://html.spec.whatwg.org/multipage/embedded-content.html Multipage: https://html.spec.whatwg.org/multipage/#dom-iframe-sandbox Complete: https://html.spec.whatwg.org/#dom-iframe-sandbox Referrer: https://html.spec.whatwg.org/multipage/index.html Comment: iframe@sandbox support should be feature-detectable. Currently, there's no feature-detection mechanism for sandbox attributes. A trivial way of adding one might be to limit iframe@sandbox attribute to reflect only known values (https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-kn own-values). Posted from: 216.239.45.87 User agent: Mozilla/5.0 (X11; CrOS x86_64 7262.33.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.37 Safari/537.36 122641 1 mkwst 2015-08-18 13:40:23 +0000 WDYT, Anne, Domenic? 122642 2 annevk 2015-08-18 14:13:39 +0000 That only works for enumerated attributes. sandbox="" is an unordered set of unique space-separated tokens. 122643 3 mkwst 2015-08-18 14:26:28 +0000 Ok. I admit, I didn't actually read the definition, but it sounded right. :) You're right that we'd need a new concept, but conceptually it'd be similar. That is, it seems reasonable to just drop unknown values on the floor during parsing, such that the following would hold: ``` var i = document.createElement('iframe'); i.sandbox = "allow-scripts lldshf"; i.sandbox.value; // "allow-scripts" ``` 122644 4 annevk 2015-08-18 14:30:40 +0000 Well, the sandbox property also returns a DOMSettableTokenList so it's not really a string. And DOMSettableTokenList cannot enforce validity of strings at the moment. So it would require quite a bit more changes I think. 122645 5 mkwst 2015-08-18 14:38:19 +0000 If modifying the attribute's behavior is more work than it's worth, I'm open to any other options. Put an inspectable enum of allowed values somewhere, done. :) 122646 6 d 2015-08-18 22:29:41 +0000 I think this would be a reasonable change to DOMSettableTokenList/DOMTokenList, to only reflect to the tokens that the browser recognizes. It would require some spec and implementation work to happen though, including a willingness to break back-compat. 122647 7 mkwst 2015-08-19 00:44:22 +0000 (In reply to Domenic Denicola from comment #6) > I think this would be a reasonable change to > DOMSettableTokenList/DOMTokenList, to only reflect to the tokens that the > browser recognizes. It would require some spec and implementation work to > happen though, including a willingness to break back-compat. Looking at IDL files, backwards compatability doesn't seem to be a big risk: there are only three DOMSettableTokenList attributes implemented in Chrome, for example. 122648 8 d 2015-08-19 04:47:50 +0000 Here is a potential plan for the required spec changes: Modifications to DOM: - Add an associated optional token validation algorithm to DOMTokenList. - Modify DOMTokenList.prototype.{add,remove,toggle,contains} to either throw or ignore their input if it the token validation algorithm is present and running it fails on a given token. Be sure to define e.g. `i.sandbox.add("valid", "invalid", "valid2")` in a well-defined way. I can see pro- and con- arguments for either behavior. - Modify DOMSettableTokenList.prototype.value's setter to run the token validation algorithm if present, before setting tokens to the result. Modifications to HTML: - Add such a token validation algorithm to HTMLIFrameElement.prototype.seamless, validating that the value is in the given set. - If possible, find other specs that could benefit from this and add algorithms to them at the same time. Anne, WDYT? 122649 9 annevk 2015-08-19 06:16:05 +0000 Sounds reasonable. And useful. 122856 10 zcorpan 2015-08-28 15:08:27 +0000 Throwing as a way to feature-detect seems more annoying than e.g. a return value. It seems to me that we don't necessarily want the API to reject invalid values, we just want to enable feature-detection. You might still want to add values that the implementation doesn't support if that makes the logic simpler. It also seems somewhat risky Web-compat-wise to start throwing. To that end, I think the minimal change is to make DOMTokenList#add have a boolean return value where, if there is token validation defined and all values added are supported, it returns true; otherwise returns false. var i = document.createElement('iframe'); var supported = i.sandbox.add("lldshf"); 122857 11 zcorpan 2015-08-28 15:10:53 +0000 Alternatively introduce DOMTokenList#supports() 122861 12 d 2015-08-28 15:37:14 +0000 It still seems valuable to me to have the built-in ways of manipulating a DOMTokenList try to preserve no-invalid-tokens. That is, having add and toggle ignore invalid tokens seems like a good change regardless. 122895 13 zcorpan 2015-08-29 16:18:08 +0000 Why? 122896 14 annevk 2015-08-29 16:46:44 +0000 It would be more consistent with "limited to known values", an existing pattern, whereas you are proposing a new pattern. 122917 15 zcorpan 2015-08-31 11:07:25 +0000 OK. Consistency with that suggests not throwing. Let's try it. 124051 16 yoav 2015-11-03 10:18:47 +0000 I like the solution outlined and it seems like it would be useful for https://github.com/w3c/preload/issues/7 as well, when used on `relList`. Having a boolean return value also has the added benefit of having legacy UAs fall into the "false" bucket for most cases, since their return value for `add()` would be `undefined`. 124052 17 Ms2ger 2015-11-03 11:47:48 +0000 The solution that's most consistent with "limited to known values" would be to make `add` return true or false depending on whether the token(s) are supported, but add all passed tokens to the content attribute regardless of whether they're supported. I suspect this is also likely the most web-compatible change. 124152 18 zcorpan 2015-11-10 12:33:36 +0000 https://github.com/whatwg/dom/pull/103 fixes this issue for the DOM spec, but the HTML spec needs to use the new hook for <iframe sandbox> (this bug) and <link rel> (bug 28796). 124698 19 d 2016-01-24 06:06:47 +0000 This is now fixed: "The supported tokens for sandbox are the allowed values defined for the sandbox attribute that are supported by the user agent."