| 00:32 | <falken> | wanderview: I don't think so. The SW still only intercepts requests from the page it's a controller of. In this case the page is a chrome extension. |
| 01:26 | <MikeSmith> | falken: not sure if you missed that you have github invite waiting, for push access to the web-platform-tests repo |
| 01:28 | <falken> | MikeSmith: thanks... I can't find the invite. Is this different from joining the web-platform-tests org? |
| 01:38 | <MikeSmith> | falken: no different; if you’re already part of the org, you can just ignore it |
| 01:39 | <MikeSmith> | I sent it to the account https://github.com/mattto |
| 01:39 | <MikeSmith> | maybe that’s not you.. |
| 01:40 | <falken> | MikeSmith: Yep that's me. I think I'm a member now. I guess that might be why the invite doesn't show up anywhere for me? |
| 01:40 | <MikeSmith> | dunno |
| 01:40 | <MikeSmith> | oh wait, the web-platform-tests org is different |
| 01:40 | <MikeSmith> | I misspoke before |
| 01:40 | <falken> | MikeSmith: oh... |
| 01:41 | <MikeSmith> | this is for https://github.com/w3c/web-platform-tests/ |
| 01:41 | <MikeSmith> | which is in the in github w3c org |
| 01:41 | <MikeSmith> | anyway, annevk is the one who actually requested that you have access |
| 01:41 | <MikeSmith> | I assume so that you could do approved revieww |
| 01:42 | <MikeSmith> | but I see now you already have read access to that repo |
| 01:42 | <MikeSmith> | which should be enough to allow you to approve reviews |
| 01:43 | <falken> | MikeSmith: OK, sounds good. odd |
| 01:43 | <MikeSmith> | yeah |
| 01:43 | <MikeSmith> | anyway, it will all be moved over to the web-platform-tests org soon |
| 01:44 | <MikeSmith> | in the mean time I can ask annevk about it later when he’s around |
| 02:30 | <falken> | MikeSmith: The invite arrived! |
| 02:31 | <falken> | MikeSmith: It just arrived now. Joined. |
| 02:32 | <falken> | MikeSmith: Well 45 minutes ago |
| 02:34 | <MikeSmith> | falken: cool |
| 02:34 | <MikeSmith> | yeah that’s because I had the system re-send it |
| 04:13 | <annevk> | I think foolip also invited falken |
| 04:16 | <falken> | annevk: yes foolip invited me to web-platform-tests org and MikeSmith to w3c org |
| 08:02 | <nox> | annevk: https://github.com/servo/servo/pull/20698/files#diff-e55587046e2aec44dd25e5e4a8958217 Does that ring a bell? Any recent changes to those? |
| 08:03 | <annevk> | nox: dunno, sorry |
| 08:05 | <nox> | annevk: No problem. Pinged you just in case, will look for the answer myself. :) |
| 08:06 | <nox> | annevk: https://github.com/w3c/web-platform-tests/commit/3e538e72b8f12de065612862486c3fc24beb9c53#diff-26c995600d11355f7b4b03f54d96cd82 😱 |
| 08:07 | <annevk> | nox: getting rid of document.origin in favor of self.origin is generally good? |
| 08:07 | <nox> | annevk: Oh yes yes, I know those changes are made for good reasons. |
| 08:07 | <nox> | But stop pointing out Servo's deficiencies with clever changes, it makes me sad. :P |
| 08:09 | <annevk> | I'm pretty sure nobody writes async/await or self.origin to spite Servo 😃 |
| 08:17 | <nox> | IT'S A CONSPIRACY |
| 08:30 | <yoav> | annevk: Can we land https://github.com/whatwg/fetch/pull/659? Or do we need to wait for the official Edge bug? |
| 08:30 | <yoav> | (I wanna land https://chromium-review.googlesource.com/c/chromium/src/+/1029858 and prefer to do it after the spec change lands) |
| 08:36 | <annevk> | yoav: nah, landed |
| 08:36 | <annevk> | yoav: thanks for working on that |
| 08:37 | <annevk> | yoav: the only other thing that can help make it go even smoother is preparing a commit message that has all the details, but happy to take care of that |
| 08:55 | <smaug____> | ahaa, webkit doesn't seem to implement delegateFocus stuff |
| 08:57 | <smaug____> | https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/dom/Element.idl#L156 vs https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/shadow_root_init.idl?q=ShadowRootInit&sq=package:chromium&dr=C&l=11 |
| 08:57 | <annevk> | I hope that's only because of lack of time and not some disagreement |
| 08:57 | <annevk> | I don't recall any disagreements at least |
| 08:57 | <smaug____> | yeah |
| 09:00 | <nox> | annevk: I'm… I'm lost. Where does window.origin come from? |
| 09:02 | <annevk> | nox: WindowOrWorkerGlobalScope |
| 09:03 | <nox> | TIL, thanks. |
| 09:03 | <nox> | annevk: // [Replaceable] readonly attribute USVString origin; |
| 09:03 | <nox> | Well that explains things. :) |
| 12:16 | <annevk> | foolip: did you ever figure out if LockCompatibilityMode et al are redundant? |
| 12:18 | <foolip> | annevk: that doesn't even ring a bell, so no :) |
| 12:19 | <foolip> | Nothing in my inbox either, what is this? |
| 12:19 | <annevk> | foolip: I thought I asked you (on IRC) if compatibility_mode_locked_ was ever false or if it could ever be |
| 12:19 | <annevk> | foolip: from document.cc (used to be Document.cpp; took a while to find the new location...) |
| 12:20 | <foolip> | annevk: oh, that. yes, my change finished running, and the results weren't what I thought. let me find it |
| 12:21 | <foolip> | annevk: https://chromium-review.googlesource.com/c/chromium/src/+/986136 |
| 12:21 | <foolip> | annevk: hmm, results don't seem to load now, I'll rebase and run again |
| 12:28 | <annevk> | foolip: I can reproduce it sometimes changing now, but I don't really understand what I'm looking at: https://github.com/w3c/web-platform-tests/pull/10679 |
| 12:28 | <foolip> | annevk: ah, actually, some results work, and point to a bunch of tests which trigger the code path we suspected was dead: https://ci.chromium.org/buildbot/tryserver.chromium.win/win7_chromium_rel_ng/133394 |
| 12:29 | <foolip> | actually https://test-results.appspot.com/data/layout_results/win7_chromium_rel_ng/133394/layout-test-results/results.html is the best starting point |
| 12:29 | <foolip> | and https://test-results.appspot.com/data/layout_results/mac_chromium_rel_ng/682797/layout-test-results/results.html |
| 12:30 | <foolip> | the first failure I looked at is a simple file at least: https://chromium.googlesource.com/chromium/src/+/1a52caad09e40377c58296887635640ec21c102b/third_party/WebKit/LayoutTests/dom/legacy_dom_conformance/html/level1/core/documentgetdoctypenodtd.html |
| 12:31 | <foolip> | annevk: does that provide any clues? |
| 12:32 | <annevk> | No |
| 12:32 | <foolip> | annevk: is it a minimized test case you need, or just to figure out what the spec should say around this? |
| 12:32 | <foolip> | "just" |
| 12:33 | <annevk> | foolip: I found a minimal test of sorts: https://github.com/w3c/web-platform-tests/pull/10679 but I've no idea what's going on |
| 12:33 | <annevk> | foolip: and yeah, I want to figure out if the spec should match this or not |
| 12:34 | <annevk> | I guess what's happening is that it starts out in standards mode, but then the parser can change that or some such |
| 12:34 | <annevk> | Ah yeah, I think I understand what's happening now |
| 12:35 | <annevk> | The testharness is delayed due to not getting a load event |
| 12:36 | <foolip> | annevk: looks like in addition to document.open(), navigation and parsing of document in XHR can also reach this code path, although I don't know if the change of mode is possible in those cases, would have to look at the different failures. |
| 12:37 | <annevk> | foolip: I suspect all HTML parser-related cases start out as no-quirks and can then be changed |
| 12:37 | <annevk> | foolip: I wonder how deterministic it changing is here though |
| 12:38 | <foolip> | annevk: from the failed assert it actually looks like it started out in quirks mode and then became standards mode |
| 12:38 | <annevk> | foolip: since you can feed the parser the doctype bits very incrementally |
| 12:38 | <annevk> | foolip: document.open() made it no-quirks; then document.close() would've made it quirks due to EOF |
| 12:39 | <foolip> | annevk: it is the transition in document.open() that you're wondering about, right? or is the document.close() thing also not well defined/interoperable? |
| 12:40 | <foolip> | annevk: do you have results from all browsers for https://github.com/w3c/web-platform-tests/pull/10679? |
| 12:43 | <annevk> | foolip: I figured out how Chrome et al work for that |
| 12:43 | <annevk> | foolip: it also appears to be fully deterministic |
| 12:43 | <annevk> | foolip: though a tad weird |
| 12:43 | <foolip> | trying Edge and Safari on BrowserStack |
| 12:43 | <annevk> | foolip: they are identical to Chrome |
| 12:43 | <foolip> | Firefox Nightly passes, but I think you knew that |
| 12:43 | <annevk> | foolip: I pushed an update that makes it match Chrome/Edge/Safari |
| 12:44 | <foolip> | Safari fails just like Chrome |
| 12:44 | <foolip> | Edge passes, but maybe you *just* updated it? |
| 12:44 | <annevk> | did |
| 12:51 | <annevk> | Still not entirely sure why it can be locked down though |
| 12:53 | <foolip> | annevk: ah, so Firefox just never "locks" it? |
| 12:54 | <foolip> | Given the 3/1 split it seems sensible to match that for test cases that aren't contrived, but I don't know if there is a simpler model than what's implemented in Blink. Maybe tkent would know this better. |
| 12:55 | <annevk> | foolip: well Firefox doesn't seem to change it here |
| 12:55 | <annevk> | foolip: I don't know if Firefox locks it |
| 12:55 | <annevk> | (or when that's observable) |
| 13:16 | <wanderview> | falken: huh... so an extension couldn't redirect a page resource to a chrome-extension:// URL and intercept it? I thought that was a prime use case |
| 13:41 | <MikeSmith> | https://stackoverflow.com/questions/50062084/how-to-fallback-to-browsers-default-fetch-handling-within-event-respondwith |
| 13:42 | <MikeSmith> | JakeA: ⬆ |
| 13:44 | <wanderview> | MikeSmith: I commented... it looks like a firefox bug that is fixed in 60 |
| 13:45 | <wanderview> | they are probably using view-source or a session restore which tries to set force-cache... but in FF59 we accidentally use only-if-cached |
| 13:48 | <annevk> | oh, I also commented |
| 13:48 | <annevk> | but I did not know that! |
| 13:48 | <MikeSmith> | wanderview: oh cool, thanks! |
| 13:50 | <MikeSmith> | thanks too annevk |
| 14:02 | <JakeA> | I guess I want make it a third comment then 😀 |
| 14:04 | <wanderview> | the real surprise is that Jeff Posnick did not comment 30 seconds after the question was asked |
| 14:08 | <annevk> | foolip: so when this file rename was done, did nobody care all the external links would be broken? |
| 14:08 | <annevk> | foolip: e.g., I have https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Node.cpp?l=2054&gsn=RemoveAllEventListenersRecursively here and it's useless now... |
| 14:09 | <annevk> | (I can make it work, but still) |
| 14:16 | <nox> | annevk: http://w3c-test.org/html/browsers/origin/relaxing-the-same-origin-restriction/document_domain_setter.html |
| 14:16 | <nox> | This seems to pass nowhere. |
| 14:17 | <nox> | We didn't have WindowOrWorkerGlobalScope.domain in Servo, just implemented it, this failed with `assert_equals: expected "http://web-platform.test:8000"; but got "http://www1.web-platform.test:8000"`, |
| 14:17 | <nox> | on all other browsers, the test doesn't even seem to pass security checks, so am scared. |
| 14:29 | <domfarolino> | annevk: Yeah that always gets&annoys me too |
| 14:29 | <nox> | I don't even understand why that test should pass. :/ |
| 14:31 | <wanderview> | annevk: does cs.chromium.org not offer permalinks? |
| 14:32 | <annevk> | wanderview: dunno, the links I had don't work across renames at least |
| 14:32 | <annevk> | nox: hmm |
| 14:32 | <wanderview> | annevk: we have the same problem in gecko... but we suggest people use permalinks in code comments and bugs, etc |
| 14:33 | <annevk> | nox: I guess you'd have to look into blames |
| 14:33 | <annevk> | wanderview: ooh I see, with the commit in there |
| 14:33 | <annevk> | dunno if that's available |
| 14:34 | <annevk> | wanderview: those also annoy me a tiny bit because it's always hard to work myself back to master |
| 14:34 | <nox> | annevk: Is there anything in the specs that say that .origin should be stripped of some subdomain prefix? |
| 14:35 | <annevk> | nox: the serialized origin should be immutable I think |
| 14:35 | annevk | double checks |
| 14:35 | <annevk> | nox: yeah, it doesn't care about origin's domain field |
| 14:36 | <annevk> | nox: so document.domain can't affect origin |
| 14:36 | <nox> | Mmh… |
| 14:36 | <annevk> | (i mean, it can affect the concept, but not self.origin) |
| 14:37 | <nox> | annevk: Ok, so I *think* the test is just dumb, even disregarding the security failures on all major browsers. |
| 14:37 | <nox> | annevk: This https://github.com/w3c/web-platform-tests/blob/master/html/browsers/origin/relaxing-the-same-origin-restriction/document_domain_setter.html#L19-L20 sets the iframe URL to some www1.… URL, |
| 14:38 | <nox> | and window.origin is http://web-platform.test:8000, |
| 14:38 | <nox> | so AFAIK iframe.contentWindow.origin can never be equal to window.origin. |
| 14:43 | <annevk> | nox: you might wanna look at blame |
| 14:43 | <annevk> | nox: Servo folks wrote that test |
| 14:43 | <nox> | LOL |
| 14:44 | <nox> | annevk: I just pinged Alan because I knew he did cross-origin stuff and he may be interested into looking at the failures, and I had not even noticed he wrote it. :) |
| 14:45 | <annevk> | nox: if you're worried about security run https://github.com/w3c/web-platform-tests/tree/master/html/browsers/origin/cross-origin-objects btw |
| 14:45 | <nox> | annevk: Noted. |
| 14:45 | <nox> | annevk: I'm under three layers of interdependent blocked upgrades, I just want to land stuff rn. :) |
| 14:46 | <annevk> | I've lost trace of my stack, but I'm still doing stuff with document.open() so I guess it's all good |
| 14:48 | <nox> | annevk: Ah ah ah. |
| 14:57 | <ajeffrey_> | nox: okay, looking... |
| 15:08 | <ajeffrey_> | nox: OK, so there's three things going on in https://github.com/w3c/web-platform-tests/blob/master/html/browsers/origin/relaxing-the-same-origin-restriction/document_domain_setter.html... |
| 15:09 | <ajeffrey_> | 1) https://github.com/w3c/web-platform-tests/blob/master/html/browsers/origin/relaxing-the-same-origin-restriction/document_domain_setter.html#L49 does look to be a bug, it assumes origin gets changed to match domain, which it shouldn't. |
| 15:11 | <ajeffrey_> | 2) Rather annoyingly, some of the tests are failing under FF because it's throwing a different kind of security error: "function() { document.domain = SUFFIX_HOST; }" threw object "NS_ERROR_DOM_BAD_DOCUMENT_DOMAIN: Illegal document.domain value" that is not a DOMException SecurityError |
| 15:12 | <ajeffrey_> | 3) The test assumes that a cross-origin frameElement is null rather than a security exception. I'd need to check the spec here, but there's a good chance this is also a bug with the test. |
| 15:17 | <nox> | ajeffrey_: I marked it as failing in Servo, FYI. |
| 19:55 | <annevk> | Would be good to have an issue on that test too |
| 19:55 | <annevk> | I can look at fixing it… |
| 20:01 | <nox> | annevk: https://github.com/w3c/web-platform-tests/issues/10695 |
| 20:20 | <foolip> | annevk: I assume people realized that would happen but weren't the same people who could set up a bunch of redirects |
| 20:21 | <foolip> | FWIW, whenever I link to something with line numbers I make sure it includes the hash, otherwise it'll be broken before long rename or not |
| 20:21 | <foolip> | A bit of extra work, I know |