| 02:26 | <sideshowbarker> | Noam Rosenthal: thanks for doing that |
| 08:40 | <hsivonen> | AFAICT, https://github.com/web-platform-tests/wpt/blob/master/upgrade-insecure-requests/gen/iframe-blank-inherit.meta/upgrade/fetch.https.html tests that calling document.open() on the initial about:blank inherits upgrade-insecure-requests from the caller to the open()ed doc. I don't see this specified in either https://w3c.github.io/webappsec-upgrade-insecure-requests/ or https://html.spec.whatwg.org/#document-open-steps . What am I missing? (Also, Gecko tries to inherit CSP between steps 6 and 7, but evidently, it's not inheriting enough.) |
| 10:49 | <Domenic> | hsivonen: seems like a bad test. I can't immediately tell given how many layers of generation seem to be going on but I would doubt that was intentionally tested... |
| 10:50 | <Domenic> | This code looks totally bogus in Chromium to me... https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/document.cc;l=3257-3285;drc=6bf619d06ef290056d3e134756c1c4eaa17a2d70 |
| 10:50 | <hsivonen> | The test was OK after all. I tracked it down to Gecko's failure to recompute upgrade-insecure-requests upon document.open |
| 10:51 | <hsivonen> | (Gecko copied the CSP OK, but failed to actually run the function to compute upgrade-insecure-requests out of the CSP) |
| 10:51 | <Domenic> | Fascinating |
| 10:52 | <Domenic> | I am hoping we can avoid inheriting anything, whether it's Gecko's CSP or Blink's renderer-process-only sandbox flags / security origin |
| 10:53 | <hsivonen> | (Aside: The way fetch() spec-wise inherits CSP from the doc in the window that fetch() is called on, is specified so abstractly that I wasn't confident how upgrade-insecure-requests should propagate, but it turns out that it should propagate from doc to fetch().) |
| 10:54 | <Domenic> | Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1360795 |
| 10:56 | <Domenic> | Note that the spec's "URL and history update steps" usage is probably not web-compatible... we should probably add a warning... see https://github.com/whatwg/html/issues/6556 |
| 10:58 | <hsivonen> | Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1360795 |
| 11:03 | <hsivonen> | Note that the spec's "URL and history update steps" usage is probably not web-compatible... we should probably add a warning... see https://github.com/whatwg/html/issues/6556 |
| 11:03 | <Domenic> | Yes, thanks, fixed |
| 11:04 | <Domenic> | Currently, I'm finding that tests that test history length start failing with my patch but they already fail in Chrome and pretty consistently if I remove expectations for history length to grow by one more than Chrome grows it, the tests pass both in Chrome and in Firefox+my patch. |
| 11:05 | <hsivonen> | For document.open() specifically, or other places? |
| 11:11 | <hsivonen> | Back in 2011 when I tried to change how Gecko handles about:blank, I got failures on history mochitests but didn't have a way to run the same tests in another engine like I can now run WPT to see that the test expectations differ from Chrome and my patch actually moves towards interop despite failing tests. |