08:58
<annevk>
jgraham_: why does the port for web-platform.test keep changing?
09:04
<jgraham>
annevk: By default it should start one server on port 8000 and one on a random free port
09:04
<jgraham>
In general you aren't supposed to rely on the specific port in tests (but obviously for actually running them having a known port helps, hence 8000)
09:05
<annevk>
jgraham: the random port makes it hard with popup preferences
09:05
<annevk>
jgraham: but 8000 helps
09:06
<jgraham>
Do popup preferences also consider port?
09:06
<annevk>
jgraham: they do in Gecko these days
09:06
<jgraham>
Oh
09:07
<annevk>
jgraham: we changed from hostname to origin checks for everything a while back
09:07
<annevk>
jgraham: and * does not work
09:07
<annevk>
jgraham: web-platform.test:* that is
09:07
<jgraham>
For something like popup blocking that seems unfortunate from a UI point of view
09:11
<annevk>
jgraham: I also keep having this change to tools "Subproject commit d93ad88336e5933b158129596c196d568ae15f82-dirty"
09:12
<annevk>
jgraham: even when I do git reset --hard
09:12
<jgraham>
Yeah, submodules :(
09:12
<jgraham>
I think something in the .gitignore needs to be updated
09:12
<jgraham>
I'll have a look in a moment
09:14
<annevk>
I wonder if I should file a bug on the popup preferences thing... It seems kind of lame to file this bug for a test framework
09:19
<jgraham>
Well I can't imagine anyone is going to think it's a P1
09:19
<jgraham>
FWIW I think I might have the popup blocker disabled. Herd immunity and all that
09:36
<jgraham>
annevk: What does git status show if you run it from tools/
09:39
<annevk>
HEAD detached at d93ad88
09:39
<annevk>
nothing to commit, working directory clean
09:39
<annevk>
jgraham: ^
09:42
<Ms2ger>
Where's the chromium dashboard for features they measure?
09:44
<jgraham>
annevk: Hmm. To be clear, what happens if you run git submodule update --recursive in the main wpt checkout?
09:44
<annevk>
Ms2ger: https://www.chromestatus.com/metrics/feature/timeline/popularity
09:45
<annevk>
jgraham: that seems to return pretty quickly
09:45
<Ms2ger>
Thanks
09:46
<Ms2ger>
Doesn't look like MouseEvent#toElement is going anywhere: https://www.chromestatus.com/metrics/feature/timeline/popularity/507
09:48
<jgraham>
annevk: And git status doesn't change?
09:48
<annevk>
jgraham: correct
10:02
<jgraham>
r? https://github.com/w3c/wpt-tools/pull/38 https://github.com/w3c/web-platform-tests/pull/2328
10:03
<Ms2ger>
Looking
10:04
<Ms2ger>
jgraham, conflicts on wpt
10:05
<jgraham>
Oh, dammit
10:06
<jgraham>
I didn't notice I was on a strange branch
10:09
<jgraham>
Ms2ger: Try again
10:39
<annevk>
Why does html/ have all these empty directories with .gitkeep files in them?
10:40
<jochen__>
annevk: do you know what's up with referrerPolicy attribute over at mozilla?
10:40
<annevk>
Is there an easy way to find out if there are any noreferrer tests?
10:41
<annevk>
jochen__: I think hsivonen was looking for confirmation from you that the name is set and agreed upon?
10:41
<annevk>
jochen__: see https://github.com/w3c/webappsec-referrer-policy/issues/3#issuecomment-156685673
10:42
<annevk>
jochen__: I haven't really followed any corresponding issues in Mozilla's Bugzilla though
10:42
annevk
looks
10:42
<Ms2ger>
html/browsers/windows/browsing-context-names/001.html:<title>Link with target=_blank, rel=noreferrer</title>
10:43
<jochen__>
I don't understand why he even asks
10:43
<Ms2ger>
html/semantics/links/linktypes/contains.json: "original_id": "link-type-noreferrer"
10:43
<jochen__>
the only reason this doesn't make much progress is because somebody else from mozilla wants to spec it, but only sends a pull request every few weeks :-/
10:44
<annevk>
jochen__: that person is not from Mozilla
10:45
<annevk>
jochen__: pretty sure that person is employed by Yahoo!
10:45
<annevk>
jochen__: why is it an unreasonable question?
10:46
<annevk>
jochen__: I think hsivonen just wants to be certain about the name change, since he was asked to review https://bugzilla.mozilla.org/show_bug.cgi?id=1187357 (which appears to be the corresponding bug)
10:47
<jochen__>
annevk: no, the question is not unreasonable
10:47
<jochen__>
guess I should just update the spec myself
10:48
<annevk>
jochen__: seems reasonable if Scott is not active/away
10:48
<philipj>
annevk, mkwst, where is https://url.spec.whatwg.org/#concept-urlencoded-string-parser actually defined?
10:49
<annevk>
philipj: that is a definition?
10:49
<annevk>
philipj: it's a tad confusing that "parsing" is not part of the link though
10:50
<philipj>
the URLSearchParams constructor refers to it, so I'm looking for something that actually splits of '&' and so on
10:50
<annevk>
philipj: right, click on "application/x-www-form-urlencoded"
10:51
<philipj>
oh, well that wasn't obvious :)
10:51
<philipj>
since it was under "Hooks" I assumed I should be looking for it in some other spec
10:51
<Ms2ger>
That link should probably include "parsing" too
10:51
<annevk>
Ms2ger: yeah, just said that
10:52
<annevk>
Ms2ger: PRs welcome
10:52
<Ms2ger>
Do
10:52
<Ms2ger>
h
10:54
philipj
does it
10:55
<annevk>
jgraham: so apart from finding it hard to find tests, I'm also having a hard time to figure out where to put tests
10:56
<Ms2ger>
I guess your test spans a number of spec sections
11:02
<philipj>
annevk: https://github.com/whatwg/url/pull/73
11:05
<annevk>
Ms2ger: yeah, also, I've no idea how to do this properly
11:05
<annevk>
So I spawn a new window; I need to test something in that window, then the only way I can communicate back is through document.cookie or localStorage
11:05
<annevk>
Can I use document.cookie and localStorage without fear of breaking stuff?
11:06
<annevk>
Or do I need to use some kind of framework that prevents misuse?
11:08
<philipj>
annevk: if you have arranged things so that there is only ever one things that writes to a specific localStorage key, and the others just read, then I can't see what implementation strategy would break that
11:08
<philipj>
but perhaps I need more imagination :)
11:08
<annevk>
philipj: my problem is mostly other tests
11:09
<annevk>
philipj: but I guess if I make the name unique enough and remove it afterwards there's not much that can go wrong
11:09
<annevk>
philipj: of course, testing anything cross-origin still seems hard
11:09
<philipj>
well then localStorage isn't part of the equation anyway :)
11:14
<jgraham>
annevk: There's no generic way of cleaning up all possible state that a test could leave, although there are affordances in testharness.js for writing custom cleanup
11:14
<jgraham>
test.add_cleanup(callback)
11:15
<jgraham>
annevk: It being hard to find tests and hard to know where to put tests are two sides of the same coin, really. I'm not sure what the solution is, especially for cross-cutting tests
11:18
<annevk>
philipj: yeah, I basically don't see how that could be tested
11:18
<annevk>
philipj: manually I suppose
11:50
<annevk>
jgraham: so web-platform-tests now has three review systems?
11:52
<jgraham>
annevk: I have no idea why reviewable is on
11:52
<jgraham>
Ms2ger: ^?
11:53
<jgraham>
I mean if people prefer that to critic we can use it instead when I have my bot for automatically cc-ing potential reviewers done
11:53
<Ms2ger>
I wanted to use it somewhere, but I don't remember why, feel free to turn it off again for now
11:55
<jgraham>
OK
13:36
<JonathanNeal>
Has there been a proposal to shorthand data attribute selectors? something like http://jonathantneal.github.io/postcss-short-data/ ?
14:25
<annevk>
JonathanNeal: seems like something for #css on W3C IRC?
14:27
<annevk>
JakeA: if for some reason a document terminates a fetch, should the service worker one keep trucking? Should there be some way to forward the signal?
14:28
<JonathanNeal>
annevk: thanks, i wasn’t sure where the discussion belonged
14:44
<JakeA>
annevk: I'm hoping it could cancel the promise passed to respondWith
14:45
<JakeA>
But the fetch event's respondWith and waitUntil are no longer valid for keeping the SW open if the fetch is aborted
14:47
<annevk>
Hmm
14:47
<annevk>
I don't think any of that is specified
14:57
<wanderview>
annevk: JakeA: we're only talking if the service worker does fetch(evt.request), right?
14:58
<wanderview>
oh, I see... cancelling the promise to respondWith() would work for any fetch()
14:59
<wanderview>
although I wonder if it would play havoc with people trying to do read-through-caching strategies... they may still want to update cache in those cacses
14:59
<wanderview>
cases
14:59
wanderview
should not be typing here without at least one cup of coffee.
15:08
<Ms2ger>
> By all means, I'm no expert on collapsing margins since I just learned about them today, but does the spec really make sense...
15:08
<Ms2ger>
Oh poor soul
15:30
<annevk>
wanderview: how does cancelling respondWith() affect an ongoing fetch() from the service worker?
15:31
<wanderview>
annevk: I was assuming the cancellable promises and aborting fetch would be spec'd at this point
15:32
<annevk>
wanderview: hmm, I guess we can wait for that until we clarify this further
15:32
<annevk>
wanderview: it does kind of make sense that if you do a passthrough the cancellation affects both
15:36
<wanderview>
annevk: its unclear to me if all things the SW might do will be cancellable, though... like I haven't heard anyone suggest cache.put() should cancellable
15:37
<annevk>
wanderview: cancelable by the developer or cancelable by the user?
15:37
<annevk>
wanderview: or cancelable due to some system fault?
15:44
<wanderview>
annevk: I mean something like cache.put(req, resp).cancel();
15:44
<wanderview>
annevk: something like cache.add(req) might need to be cancellable since it does a fetch() internally... but I guess I wonder if we should allow cancelling the disk transaction
15:45
wanderview
foresees headaches.
16:04
<annevk>
jgraham: Ms2ger: that change you landed to ignore tools doesn't actually ignore it
16:04
<annevk>
jgraham: Ms2ger: my local checkout claims I have changed the commit value to d93ad88336e5933b158129596c196d568ae15f82 (no longer has dirty at the end)
16:05
<annevk>
jgraham: Ms2ger: running "git submodule update --recursive" did not help
16:05
<Ms2ger>
annevk, try git submodule update --recursive
16:05
<Ms2ger>
Bah
16:15
<annevk>
jgraham: apart from that, question, where do manual tests go?
16:16
<Ms2ger>
Same place as automated tests, but called foo-manual.html
16:17
<annevk>
Okay
16:17
<annevk>
ta
16:19
<Ms2ger>
Np
17:51
<annevk>
Ms2ger: jgraham: so I did the "git submodule update --recursive" thing in the wrong branch
17:51
<annevk>
Ms2ger: jgraham: seems all is good now
17:52
<Ms2ger>
\o/
17:53
<annevk>
yeah that is actually pretty much \o/
17:53
<annevk>
this was quite annoying
17:59
<jgraham>
Submodules have rough edges
17:59
<jgraham>
I would happily not use them here, except css
18:03
<annevk>
Oops, I broke Critic
18:03
<annevk>
Did not appreciate force push
18:03
<jgraham>
Which PR?
18:04
<annevk>
jgraham: https://github.com/w3c/web-platform-tests/pull/2329
18:12
<jgraham>
annevk: Well working again now fwiw
19:00
<smaug____>
is there some way in chrome to make it open about:blank by default
19:00
<smaug____>
in new tabs
20:13
<hsivonen>
annevk: Is our encoding handling for MIME header parsing spec-compliant? See https://mxr.mozilla.org/mozilla-central/ident?i=nsIUTF8ConverterService . That code seems to treat bytes as UTF-8 if they look like UTF-8 and treat them as another encoding otherwise
23:50
<smaug____>
jgraham: I probably asked this before, but we don't have too many tests for MessagePorts, right? Do you happen to know if anyone is writing such?