| 05:46 | <ondras> | so, https://bugs.chromium.org/p/chromium/issues/detail?id=763298 |
| 05:47 | <ondras> | does it make sense to adjust the spec so it allows @page { margin: var(--...) } ? |
| 07:52 | <annevk> | ondras: prolly, but best tracked at https://github.com/w3c/csswg-drafts/issues/new |
| 08:02 | <MikeSmith> | annevk: about the <wpt> element, what’s the priority feature of it for you? |
| 08:03 | <MikeSmith> | for wattsi I already have a patch for the the display/output part of it ready |
| 08:03 | <MikeSmith> | but implementing the checks against the wpt repo is a whole nother things |
| 08:04 | <annevk> | MikeSmith: I don't really care for it I think |
| 08:04 | <ondras> | annevk: thanks, I wanted to make sure that the idea is not a complete nonsense prior to submitting it to github |
| 08:04 | <annevk> | MikeSmith: I also think it's somewhat problematic that it creates a strong mutual link between the two repositories |
| 08:04 | <annevk> | MikeSmith: someone landing a new HTML test can break the HTML build |
| 08:05 | <annevk> | ondras: it seems reasonable, prolly not done to keep things simple |
| 08:05 | <ondras> | annevk: ok |
| 08:08 | <MikeSmith> | annevk: yeah that’s how it seems to me too, as far as HTML |
| 08:09 | <MikeSmith> | so unless Simon feels different and has a compelling argument, I guess for HTML we don’t want to do the checkes |
| 08:10 | <MikeSmith> | annevk: but you like having the tests-infor display part of it in the spec output? |
| 08:10 | <MikeSmith> | or you don’t like that part either? |
| 08:11 | <annevk> | MikeSmith: I dunno, I haven't really used the system so I'm not the best judge |
| 08:14 | <MikeSmith> | ok |
| 08:15 | <MikeSmith> | I guess we really would want to get agreement before really doing it for HTML |
| 08:16 | <MikeSmith> | because “really doing it” means somebody going in and adding <wpt> elements for several thousand test files, all throughout the source |
| 08:39 | <annevk> | MikeSmith: yeah, we should discuss the tradeoffs there, agreed |
| 08:39 | <hsivonen> | Did Chrome remove FTP support already? |
| 08:40 | <annevk> | hsivonen: for subresources I think, not in general, but I might be mistaken |
| 08:40 | <hsivonen> | annevk: ok. |
| 08:40 | <MikeSmith> | annevk: ok, will see what Simon has to say |
| 08:40 | <hsivonen> | (I made the mistake of looking at our FTP code. It has comments about VMS.) |
| 08:43 | <annevk> | hsivonen: I checked, only found a subresources intent (and one to mark ftp insecure in the address bar) |
| 08:48 | <hsivonen> | annevk: thanks |
| 10:45 | <annevk> | JakeA: do you have a pattern for running a test in a service worker controlled page? |
| 10:45 | <annevk> | JakeA: seutp a service worker, create an iframe with a URL that contains the test, then post the results to the parent? |
| 10:45 | <annevk> | JakeA: is that the best we have? |
| 10:49 | <JakeA> | annevk: The iframe is same origin, so you don't need to post message, but yes |
| 10:51 | <JakeA> | annevk: there's also fetch_tests_from_worker if the tests need to run in the service worker https://github.com/web-platform-tests/wpt/blob/master/fetch/range/sw.https.window.js |
| 10:51 | <JakeA> | But otherwise, you just operate on iframe.contentWindow.fetch or whatever, if you want to fetch via a service worker |
| 10:55 | <annevk> | JakeA: iframe.contentWindow.fetch fetches outside the service worker in Fx at least |
| 10:55 | <annevk> | JakeA: and I think Fx might be correct, given that we consistently refer to the "current global object" |
| 10:55 | <annevk> | JakeA: and not "relevant global object" |
| 10:57 | <JakeA> | annevk: oh, really? Ah, well, a lot of my tests rely on the other thing, so I guess I'll need to fix them (although, I'd have expected it to have worked) |
| 10:59 | <annevk> | JakeA: yeah, afaict |
| 12:31 | <annevk> | JakeA: maybe something else is wrong though |
| 12:37 | <annevk> | wanderview: https://github.com/web-platform-tests/wpt/pull/12680 now uses an <iframe> but I still get the weird result with Firefox returning the request URL |
| 12:53 | <wanderview> | annevk: huh... I would expect that test to get "test.txt" in firefox... the response URL without the fragment |
| 12:54 | <wanderview> | annevk: firefox has response URL setting, but it still strips response fragments AFAIK |
| 12:54 | <wanderview> | since I think that part is still to be spec'd? |
| 12:54 | <annevk> | wanderview: yeah, without fragment is what I get in Chrome, as expected |
| 12:54 | <annevk> | wanderview: but Fx gives /test |
| 12:55 | <wanderview> | I guess it would be useful to know if your service worker script is actually getting the expected fetch events |
| 12:57 | <annevk> | wanderview: I think it does since it does say that /test was transferred via the service worker |
| 12:58 | <annevk> | wanderview: and Fx does return the text contents of test.txt when asked |
| 13:01 | <wanderview> | annevk: sounds like a bug to me... maybe the fragment on the response URL is making it take an untested path |
| 13:01 | <wanderview> | if you put it in a glitch I could play around with it, but I don't have firefox build handy |
| 13:03 | <wanderview> | let me see what WPT changes were made with that code change |
| 13:04 | <annevk> | Same without a fragment |
| 13:05 | <annevk> | I don't really know how glitch works |
| 13:05 | <annevk> | Anyway, I guess I'll file bugs, since this being different is a problem either way |
| 13:05 | <wanderview> | annevk: for reference, this behavior should have been enabled in firefox in https://bugzilla.mozilla.org/show_bug.cgi?id=1222008 |
| 13:07 | <wanderview> | I'll put it in a glitch... because I'm curious |
| 13:14 | <annevk> | wanderview: do you think it's reasonable btw if I extend the fragment-frame.html resource with more tests, put all the results in an array, and then use parent.reject/parent.resolve to report the results |
| 13:14 | <annevk> | wanderview: it's not great, but I'm not really sure what else is available |
| 13:14 | <annevk> | JakeA: ^^ |
| 13:14 | <wanderview> | annevk: I find it easier to use an empty frame and `frame.contentWindow.fetch()` from the parent test |
| 13:14 | <wanderview> | but its probably a style thing... |
| 13:15 | <annevk> | wanderview: I wasn't sure whether that's actually correct |
| 13:15 | <wanderview> | we do it all over the place |
| 13:15 | <annevk> | wanderview: since in that case the "current global object" would be the global of the parent, not the frame? |
| 13:15 | <wanderview> | annevk: the service worker tests use that pattern a lot |
| 13:16 | <annevk> | wanderview: sure, but is it correct? |
| 13:16 | <annevk> | wanderview: I don't think it is per spec, unless I missed something |
| 13:16 | <wanderview> | annevk: I think it is, but I don't have time to look it up right now |
| 13:17 | <JakeA> | What do we generally use in terms of fetching? Eg, what does createElement("img") do if you add a src? |
| 13:17 | <annevk> | JakeA: that uses the node document's relevant global object prolly |
| 13:18 | <annevk> | https://fetch.spec.whatwg.org/#dom-global-fetch invokes new Request() (unclear from which global, I think there's an issue on that) |
| 13:19 | <annevk> | new Request() sets client to the current global object, which would always be parent if you do frame.contentWindow.fetch() I think |
| 13:19 | <annevk> | So I think the existing pattern is at odds with the spec |
| 13:20 | <annevk> | I'm not trying to defend the spec btw; clearly it wasn't tested properly |
| 13:20 | <annevk> | isn't* |
| 13:24 | <wanderview> | annevk: here is the glitch version: https://sw-fetch-final-response-url.glitch.me/ |
| 13:24 | <wanderview> | annevk: and yea, it seems like the final URL replacement is not working for some reason |
| 13:26 | <annevk> | wanderview: JakeA: I think https://github.com/whatwg/fetch/issues/777 tracks the realm/global/settings object issue |
| 13:28 | <annevk> | wanderview: JakeA: note that even if I could use frame.contentWindow.fetch(), that would still result in overall failure upon the first failure |
| 13:29 | <annevk> | wanderview: JakeA: or would you then just make new promise_test wrappers for each scenario? |
| 13:29 | <wanderview> | annevk: separate promise_test for each case so that browsers can mark them individually expected pass/fail |
| 13:29 | <wanderview> | IMO |
| 13:30 | <annevk> | wanderview: but you'd setup the SW in the first test? |
| 13:30 | <annevk> | I guess that's okay... |
| 13:30 | <wanderview> | annevk: I usually setup/teardown the service worker in each test case... but chromium team has been moving new tests to a "setup" case at the beginning that setups up the SW registration |
| 13:30 | <wanderview> | to make the tests faster |
| 13:32 | <JakeA> | Interesting. I'd been setting up per test, but I guess one is fine. Is setup able to be async yet? |
| 13:32 | <JakeA> | I remember that being a problem |
| 13:34 | <wanderview> | folks seem to prefer promise_test to make things sequential |
| 13:34 | <annevk> | I was thinking just using promise_test and making the title "setup" |
| 13:35 | <JakeA> | annevk: I've done that before too. Works well. |
| 13:35 | <annevk> | and maybe nest the other promise_tests inside so cleanup remains working well... |
| 13:41 | <wanderview> | annevk: would you like me to file the final response URL bug? |
| 13:47 | <annevk> | wanderview: sure |
| 14:00 | <wanderview> | annevk: I think this is a problem in fetch() ignoring URL changes for internal redirects |
| 14:04 | <wanderview> | annevk: yep, that is the problem: https://searchfox.org/mozilla-central/rev/e126996d9b0a3d7653de205898517f4f5b632e7f/dom/fetch/FetchDriver.cpp#1285 |
| 14:04 | <wanderview> | annevk: filed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1486445 |
| 14:04 | <wanderview> | should be an easy fix once you have tests |
| 16:33 | <annevk> | wanderview: sorry for the slow turnaround, but I added a couple more tests at https://github.com/web-platform-tests/wpt/pull/12680 now |