Re: HTML spec changes about data: URIs and origins
On 11/07/2016 10:41 PM, smaug wrote: Just to get some idea how many tests would be broken: https://treeherder.mozilla.org/#/jobs?repo=try&revision=28735d0f2e5516c5a6d1f7805a065a6edbd8f28b The results show that quite a few tests need to be fixed, if we want to change data: handling. Should we start doing that? I think we should since eventually we should become compatible with other engines. (I'm still busy fixing browser chrome tests to work with proper Promise scheduling, so can't help here quite yet) -Olli On 09/13/2016 03:31 PM, Frederik Braun wrote: Firefox treats iframes pointing to a data URL as same-origin. This is all well-known, was part of the HTML spec and has been discussed before [1,2] What has changed now is the HTML spec text[3]: Given that EdgeHTML, Webkit and Blink violated this requirement, the standard now turned around and assigns them a unique opaque origin. I'll gladly accept the fact that we are not the violator, given the security implications [1]. The GitHub related issue[4] included a discussion with some of our DOM folks, but did not come to a conclusion as to what we plan to do here. Is back compat the main concern? I'd be happy to add a telemetry probe and a devtools warning if someone is willing to point me in the right direction. Thanks, Freddy [1] https://bugzilla.mozilla.org/show_bug.cgi?id=255107 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1018872 [3] https://github.com/whatwg/html/commit/00769464e80149368672b894b50881134da4602f [4] https://github.com/whatwg/html/issues/1753 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTML spec changes about data: URIs and origins
Just to get some idea how many tests would be broken: https://treeherder.mozilla.org/#/jobs?repo=try&revision=28735d0f2e5516c5a6d1f7805a065a6edbd8f28b On 09/13/2016 03:31 PM, Frederik Braun wrote: Firefox treats iframes pointing to a data URL as same-origin. This is all well-known, was part of the HTML spec and has been discussed before [1,2] What has changed now is the HTML spec text[3]: Given that EdgeHTML, Webkit and Blink violated this requirement, the standard now turned around and assigns them a unique opaque origin. I'll gladly accept the fact that we are not the violator, given the security implications [1]. The GitHub related issue[4] included a discussion with some of our DOM folks, but did not come to a conclusion as to what we plan to do here. Is back compat the main concern? I'd be happy to add a telemetry probe and a devtools warning if someone is willing to point me in the right direction. Thanks, Freddy [1] https://bugzilla.mozilla.org/show_bug.cgi?id=255107 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1018872 [3] https://github.com/whatwg/html/commit/00769464e80149368672b894b50881134da4602f [4] https://github.com/whatwg/html/issues/1753 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTML spec changes about data: URIs and origins
On 9/14/16 2:01 AM, Daniel Veditz wrote: Since Gecko is the only engine that behaves this way we can be reasonably sure we won't find public "must use Firefox" web sites depending on this behavior. I wish that were true. In practice, I will be pleasantly surprised if we don't find such sites, or rather sites that browser-sniff and have different codepaths (e.g. using data: in Firefox and blobs otherwise). -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTML spec changes about data: URIs and origins
On Tue, Sep 13, 2016 at 12:25 PM, Boris Zbarsky wrote: > Probably; we know they get created; what we don't know is how they're used. Since Gecko is the only engine that behaves this way we can be reasonably sure we won't find public "must use Firefox" web sites depending on this behavior. Internal corporate/educational apps maybe, add-ons almost certainly, and our tests definitely. - Dan Veditz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTML spec changes about data: URIs and origins
On 9/13/16 3:15 PM, Frederik Braun wrote: First of all, just to see how much breakage to expect when doing this on the web. Right, but my question is how you plan to measure that. So I wonder, is there a code path that we'd always call for DOM access to other window objects than the current global scope (e.g., iframes, popups), which have a data URL? There's a code path that we always call for access across windows, yes. See cross-compartment proxies. That codepath knows nothing about data URLs and is rather performance-sensitive. You _could_ perhaps subclass them in the case when the target compartment comes from a data: URL and get somewhere that way. Again, you'd need to do that without regressing peformance for all cross-window access. I assume the mere creation of those iframes/popups is possibly less useful. Probably; we know they get created; what we don't know is how they're used. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTML spec changes about data: URIs and origins
On Tue, Sep 13, 2016 at 5:02 PM, Boris Zbarsky wrote: > On 9/13/16 8:31 AM, Frederik Braun wrote: >> I'd be happy to add a telemetry probe > > > For what, exactly? What do you propose to measure? > First of all, just to see how much breakage to expect when doing this on the web. So I wonder, is there a code path that we'd always call for DOM access to other window objects than the current global scope (e.g., iframes, popups), which have a data URL? I assume the mere creation of those iframes/popups is possibly less useful. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTML spec changes about data: URIs and origins
On 9/13/16 8:31 AM, Frederik Braun wrote: Is back compat the main concern? Yes. Both for websites and addons. There's also a largish amount of work involved in auditing our tests to make sure the change doesn't make a bunch of security tests stop testing what they're trying to test, plus fixing tests that actually start failing, etc. But that's at least under our control. I'd be happy to add a telemetry probe For what, exactly? What do you propose to measure? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTML spec changes about data: URIs and origins
On Tue, Sep 13, 2016 at 2:31 PM, Frederik Braun wrote: > Is back compat the main concern? I'd be happy to add a telemetry probe > and a devtools warning if someone is willing to point me in the right > direction. As I understand it the main potential problem is addons, coupled with internal tests that need to be rewritten by someone. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
HTML spec changes about data: URIs and origins
Firefox treats iframes pointing to a data URL as same-origin. This is all well-known, was part of the HTML spec and has been discussed before [1,2] What has changed now is the HTML spec text[3]: Given that EdgeHTML, Webkit and Blink violated this requirement, the standard now turned around and assigns them a unique opaque origin. I'll gladly accept the fact that we are not the violator, given the security implications [1]. The GitHub related issue[4] included a discussion with some of our DOM folks, but did not come to a conclusion as to what we plan to do here. Is back compat the main concern? I'd be happy to add a telemetry probe and a devtools warning if someone is willing to point me in the right direction. Thanks, Freddy [1] https://bugzilla.mozilla.org/show_bug.cgi?id=255107 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1018872 [3] https://github.com/whatwg/html/commit/00769464e80149368672b894b50881134da4602f [4] https://github.com/whatwg/html/issues/1753 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
