07:34
<annevk>
hsivonen: it is not
08:43
<zcorpan>
hmmmm. i just realized that ::cue(c::before) { content: url(image) } is possible...
09:11
<annevk>
jgraham: is the localStorage issue in https://github.com/w3c/web-platform-tests/pull/2329 that mkwst points out really an issue?
09:12
<mkwst>
annevk: It will be if Chrome imports the tests. We run X workers with basically random subsets of our layout tests at the same time on the same machine. I imagine Firefox shards things similarly.
09:13
<jgraham>
We don't shard things like that
09:13
jgraham
reads the issue
09:13
<annevk>
mkwst: wouldn't that just break http://w3c-test.org/webstorage/?
09:14
<mkwst>
annevk: Probably. Those tests look like they assume they're the only thing running.
09:14
<jgraham>
mkwst: For the record, Gecko typically runs a single test process per machine, but if it didn't it would certainly use a single profile per test instance
09:14
<mkwst>
(based on random spot-checking)
09:14
<annevk>
mkwst: I suspect most tests do
09:14
<jgraham>
Servo runs multiple processes, but doesn't support storage afaik
09:15
<mkwst>
*shrug* One way around it is to use unique names, and check for those when reading storage events.
09:15
<jgraham>
Running multiple tests in parallel accessing the same underlying browser state seems like it's asking for problems
09:15
<mkwst>
jgraham: That basically "the internet", though, isn't it?
09:16
<jgraham>
… not really
09:16
<mkwst>
If you know that's a constraint, you write tests to deal with it.
09:17
<jgraham>
It sounds a bit like "programming in C is easy, just don't access invalid memory" or something :)
09:17
<jgraham>
In any case I would be interested to know what jsbell thinks because he changed the localStorage tests to clear the storage before each test
09:17
<jgraham>
*before and after
09:17
<mkwst>
jgraham: Which is why we have tools like asan. :) Basically, when they started sharding tests, it was a huge pain in the ass to get everything running because tests assumed they owned the world.
09:18
<jgraham>
s/asan/Rust/ :p
09:18
<mkwst>
Now that I'm typing all this, I guess I'm not _sure_ that we're actually sharding layout tests. Maybe we're only sharding unit tests.
09:19
<jgraham>
Anyway, ignoring the analogy, I think that running multiple tests in parallel with shared global state is asking for trouble
09:19
<mkwst>
Well, yes. I'm suggesting that "shared global state" is the problem, not "running multiple tests in parallel"
09:20
<jgraham>
Well the shared global state exists; we can't change the platform. Or make each test run in its own origin.
09:20
<jgraham>
And in some cases it is the shared global state that you are testing
09:20
<jgraham>
So you can't just never use it
09:20
<mkwst>
You can design tests not to rely on it. As I noted above: using a unique name for the storage key would help,
09:21
<jgraham>
Yes, so I agree that this test could be better
09:22
<jgraham>
But I think that running unit tests in parallel and layouttests in serial would fit more of the datapoints I have about your testing. And about what seems plausible to actually work.
09:25
<annevk>
jgraham: none of the webstorage tests appear to use unique names either
09:25
<annevk>
jgraham: e.g., view-source:http://web-platform.test:8000/webstorage/resources/local_set_item_clear_iframe.html
09:27
<mkwst>
*shrug* Ask jsbell. I might very well be wrong.
09:29
<jgraham>
annevk: Well yeah, I didn't say the existing tests were perfect :)
09:30
<mkwst>
unrelatedly: is there a web-facing API that implements https://url.spec.whatwg.org/#urlencoded-serializing?
09:30
<mkwst>
I thought `encodeURIComponent` would get me there, but it doesn't match for 0x27 (`'`).
09:31
<annevk>
mkwst: <form>
09:31
<annevk>
mkwst: ECMAScript has its own algorithms
09:31
<mkwst>
...
09:31
<jgraham>
Welcome to the web!
09:32
<philipj>
mkwst: so it didn't quite match the spec? :)
09:33
<mkwst>
philipj: I think it does match the spec, but I want to write a test that doesn't involve me hard-coding values for 0x00 -> 0xFF.
09:37
<philipj>
mkwst: wouldn't a simply encodeByte() that tests for 0x20 and the pass-through bytes between 0x2A and 0x7A be about 5 lines of code?
09:37
<philipj>
Don't need a big explicit table, I mean
09:44
<mkwst>
philipj: I might just be an idiot. *shrug* :)
09:44
<philipj>
mkwst: I really doubt it :)
09:44
<mkwst>
jgraham: Is there a mechanism to run a full test even if an assertion fails? Like, I want a list of _all_ the assertions in a test that fail, not just the first one. :)
09:45
<mkwst>
like, `expect` vs `assert` in gtest.
09:45
<jgraham>
mkwst: No
09:45
<jgraham>
Although you are not the first to ask for it
09:45
<mkwst>
:(
09:46
Ms2ger
curses the eventTestHarness.js
09:50
<annevk>
mkwst: just create a bunch of tests?
09:50
<mkwst>
I have a for loop to avoid creating a bunch of tests.
09:50
<annevk>
mkwst: multiple test/async_test in a single file that is
09:50
<zcorpan>
can encodeURIComponent be changed or will that break the web?
09:51
<mkwst>
I want to run 0x00 -> 0xFF through URLSearchParams to see what happens, and where Firefox and Chrome disagree. I don't want 255 tests.
09:51
<jgraham>
Why not?
09:52
<Ms2ger>
I think you do
09:52
<mkwst>
I think I do in testharness.js, because that's the only way to get sane error messages.
09:53
<Ms2ger>
That's what http://w3c-test.org/XMLHttpRequest/send-usp.html does too
09:53
<mkwst>
I think I don't in other testing frameworks I'm familiar with, because they don't die on the first error.
09:53
<Ms2ger>
You want it because they're independent tests
09:53
<mkwst>
Oh, ha. I hadn't thought about putting the for loop outside the `test()`. Clever!
09:53
<mkwst>
(See, philipj? Idiot. :) )
09:55
<philipj>
mkwst: Hah, still not convinced. Generating a bunch of tests is really quite nice with testharness.js, though, I like that.
09:56
<annevk>
zcorpan: battle with es-discuss?
09:56
<Ms2ger>
jgraham, oh, btw
09:56
<Ms2ger>
What's the story of content-security-policy/blink-contrib/?
09:56
<annevk>
jgraham: so do I need to change the test?
09:57
<annevk>
whoa whoa
09:57
<annevk>
web-platform-tests has 112 open PRs?
09:58
<Ms2ger>
That's all?
09:58
<Ms2ger>
I think I briefly managed to push it under a hundred early this year
10:00
<annevk>
Okay, I guess I'll just keep submitting PRs
10:01
<zcorpan>
while (zcorpan.hasChocolate() && PRs.length >= 100) { review(PRs.pop()) }
10:01
<Ms2ger>
If you can convince jst_ to hire someone to do DOM QA, we could maybe improve the situation
10:02
<jgraham>
Wait, what? If we get the queue under 100, you will stop working?
10:02
<jgraham>
That doesn't sound like an ideal incentive
10:03
<mkwst>
Ms2ger: Brad asked me to contribute all the blink CSP tests to WPT so that he'd be licensed to work on them under whatever license WPT has.
10:03
<mkwst>
So I did.
10:03
<mkwst>
And we've been converting them to testharness and WPT over time.
10:04
<annevk>
Ms2ger: that doesn't sound impossible, do you have anyone in mind?
10:04
<Ms2ger>
mkwst, so if I wanted to rewrite some of those tests to look more like native th.js tests, that wouldn't step on anyone's toes?
10:04
<Ms2ger>
annevk, not really
10:04
<mkwst>
Ok, philipj. Since you apparently know things about encodings, what is URLSearchParams supposed to produce for `0x80`? Both Firefox and Chrome produce `%C2%80`, which I guess means it's correct, but I have no idea why.
10:05
<gsnedders>
annevk: a lot of the open PRs are pretty old
10:05
<annevk>
gsnedders: yeah I noticed
10:06
<philipj>
mkwst: if you do u'\u0080'.encode('utf8') in Python it will make sense :)
10:06
<annevk>
gsnedders: I might keep noticing this every six months or so when I look into adding some tests
10:06
<gsnedders>
annevk: stuff either gets merged quickly or lasts forever, more or less :P
10:06
<mkwst>
Ms2ger: please do! If you want to be super-safe, you could ping @hillbrad to make sure he's not working on something in parallel, but I think you'll be safe.
10:06
<zcorpan>
jgraham: i know, but historically it seems we haven't managed to get the number much lower than 100. i don't know if that's because there are lots of old PRs that are really annoying to review for some reason, or we feel good about getting below 100, or both
10:06
<philipj>
U+0080 is simply those two bytes in UTF-8
10:06
<mkwst>
philipj: So, how do I write a test that produces that output? In JavaScript and not Python. :)P
10:06
<philipj>
Oh, wait, that's a very good question!
10:06
<Ms2ger>
mkwst, I'll file an issue
10:06
<jgraham>
zcorpan: I agree with gsnedders' 2-population theory. I think we probaly have a significant fraction of 100 PRs stuck for some reason
10:07
<jgraham>
e.g. too hard to review, reviewed with comments and noone addressing them, etc.
10:07
<gsnedders>
the former is something we should try and work harder on, the latter someone should pick them up
10:07
<annevk>
mkwst: (new TextEncoder()).encode("\u80") though then you still have to go from bytes to %{byte} etc.
10:07
<annevk>
philipj: ^
10:08
<mkwst>
philipj: So, it looks like Firefox and JavaScript agree on everything except "!", "(", ")", "/", and "~". I assume Firefox is correct to encode these, and Chrome is incorrect not to.
10:08
<annevk>
mkwst: you can also do it through URL parsing
10:08
<annevk>
mkwst: which uses a utf-8 encoder under the hood
10:09
<mkwst>
annevk: Well, not when URL parsing is what I'm trying to test. :)
10:10
<annevk>
mkwst: fair
10:10
<annevk>
mkwst: note https://github.com/whatwg/url/issues/18 btw
10:10
<mkwst>
TextEncoder seems to work, thanks.
10:10
<philipj>
mkwst: I actually "forgot" that there are bytes >0x7F, if you want to test all bytes you'll have to find a set of code points that contain all bytes when represented as UTF-8, but I wouldn't assume without testing that that's possible, maybe some bytes are unused in UTF-8?
10:10
<philipj>
annevk must know
10:10
<gsnedders>
philipj: FE and FF
10:10
<Ms2ger>
I don't guess anyone here has strong views on blink's webstorage layout tests that ended up in wpt?
10:11
<philipj>
gsnedders: I suspected as much
10:11
<philipj>
mkwst: but it looks like there's plenty of disagreement in the range 0x00-0x7F too :)
10:12
<mkwst>
Well, 5 characters.
10:12
<mkwst>
6 characters, sorry. Firefox gets 0x00 wrong.
10:12
<annevk>
I think bz has a patch for 0x00
10:13
<Ms2ger>
Yeah, that landed
10:13
<philipj>
I love null in strings, it's the best
10:13
<Ms2ger>
I'm glad Servo doesn't have to worry about that
10:16
<philipj>
Ms2ger: It's actually mostly a non-issue in WebKit/Blink as well, but it was a nuisance in Presto
10:16
<Ms2ger>
It's mostly a non-issue in Gecko too, but we still end up with bugs like this
10:17
<mkwst>
Ok, great. In that case, Gecko is 100% awesome, and Chrome (will be) ~98.04% awesome for the range 0x00-0xFF.
10:17
<annevk>
Ms2ger: jgraham: I think https://github.com/w3c/web-platform-tests/pull/1278 should land given that we are landing tests that check URLSearchParams() without new throws
10:18
<Ms2ger>
Ugh, I thought the spec was fixed already
10:18
<annevk>
philipj: do you remember the big Presto rewrite?
10:18
<annevk>
Ms2ger: IDL doesn't have an active editor
10:18
<philipj>
annevk: related to strings?
10:18
<Ms2ger>
> I might consider doing that if I wasn't within about a week of having to freeze the final ES6 draft.
10:18
<Ms2ger>
Yay versioning
10:19
<Ms2ger>
annevk, yeah, whatever, rebase and land it
10:19
<Ms2ger>
That ship has sailed, unfortunately
10:20
<annevk>
Ms2ger: then I get "error: The following untracked working tree files would be overwritten by checkout:"
10:20
<Ms2ger>
tools/?
10:20
<annevk>
Ms2ger: yes
10:21
<Ms2ger>
I think the easiest solution is `git checkout non-new-Blob; git branch -m non-new-Blob-old; git checkout master; git checkout -b non-new-Blob; git cherry-pick d8d1e56; git push -f origin non-new-Blob`
10:22
<annevk>
git checkout fails though
10:23
<annevk>
I hate this repo
10:23
<Ms2ger>
I'll do it
10:23
<mkwst>
philipj: Would you mind taking a look at https://codereview.chromium.org/1442643008 (the serialization in particular)?
10:24
<mkwst>
I think I've addressed all your comments.
10:24
<philipj>
gsnedders, mkwst: in some ad-hoc testing with Python it looks like only 238 unique bytes show up in UTF-8
10:24
<philipj>
mkwst: will take a look
10:26
<gsnedders>
philipj: there should be all but those two
10:26
<annevk>
gsnedders: per https://en.wikipedia.org/wiki/UTF-8#Codepage_layout there's 13
10:27
<gsnedders>
oh, right, the old four-seven byte length sequences
10:27
<gsnedders>
plus the overlong 2-byte reprs
10:27
<philipj>
I didn't go all the way up to astral, so I may have missed some
10:27
<philipj>
anyway...
10:27
<annevk>
gsnedders: four-infinite, even
10:28
<annevk>
gsnedders: I only knew about five and six
10:28
<zcorpan>
Ms2ger: can you merge https://github.com/w3c/web-platform-tests/pull/2334 ? it appeared i had too little space left to clone the repo :-(
10:28
<gsnedders>
annevk: seven/infinity were never part of UTF-8
10:28
<philipj>
I thought at some point they decided that unicode was going to be at most 24-bit to avoid the infinity problem?
10:29
<gsnedders>
annevk: they're purely theoretical extensions, that were disallowed for other reasons anyway (confusion with BOMs, most obviously)
10:29
<annevk>
philipj: well, they also decided on a 16-bit limit initially
10:29
<gsnedders>
annevk: well, depends which WG…
10:29
<annevk>
philipj: that didn't go well
10:29
Ms2ger
clicks the big green button
10:30
<philipj>
annevk: well, yeah :) the 24-bit limit seems to have done better, though
10:30
<gsnedders>
annevk: the Unicode Consortium did 16-bit, the ISO did an infinity scheme, AFAIK
10:30
<zcorpan>
Ms2ger: :-) wasn't sure about the current green-button policy for wpt
10:30
<gsnedders>
annevk: reconsiling them with Unicode 2.0 added the 21-bit restriction (for the sake of surrodates)
10:30
<philipj>
oh, was it 21 bits?
10:31
<annevk>
philipj: yeah, it's 21 at the moment
10:31
<gsnedders>
philipj: it's still 21-bit, hence 10FFFF being the max codepoint
10:31
<philipj>
ok, I just guessed a little :)
10:32
<gsnedders>
six byte UTF-8 allows 31-bit, which was the original limit of the ISO spec, apparently. My memory that it was infinite was totally wrong.
10:35
<Ms2ger>
jgraham, I wonder how you'd feel about adding something to th.js that takes an array of functions that return async_tests and runs them in sequence?
10:47
<gsnedders>
Anyone know if anyone is running the CSSWG\s tests for transitions?
10:59
<Ms2ger>
Not Servo
11:00
<gsnedders>
Despite you guys supporting some of it! :P
11:01
<Ms2ger>
Feel free to enable them :)
11:02
<gsnedders>
This, uh, may be what I'm doing.
11:03
<gsnedders>
Andseeing random noice in results in Servo.
11:03
<Ms2ger>
Lovel
11:03
<Ms2ger>
y
11:04
<gsnedders>
*noise
11:04
<gsnedders>
wondering if the tests are buggy…
11:21
<gsnedders>
they seem a bit abandoned? I have no idea how good they are
11:21
<gsnedders>
they have all kinds of JS magic involved…
11:21
<Ms2ger>
No idea
11:21
<gsnedders>
some of it is just working around the lack of async sequences
11:23
gsnedders
wopnders if the new failures in transforms are Servo breaking or your recent update
11:23
gsnedders
really can't type today…
12:52
<Ms2ger>
Hrm
12:53
<Ms2ger>
Is the storage event not fired at the window where you're making the changes?
13:04
<annevk>
Ms2ger: correct
13:04
<Ms2ger>
annevk, can you point that out in the spec?
13:06
<annevk>
Ms2ger: reverse lookup "send a storage notification"
13:07
<Ms2ger>
Gotcha, thanks
13:39
<annevk>
zcorpan: https://github.com/whatwg/html/pull/339 r?
13:46
<zcorpan>
annevk: do you have a reference at hand for people no longer wanting to support data: for workers?
13:47
<Ms2ger>
Wait, we don't? Why not?
14:11
<annevk>
zcorpan: sorry, I thought that was in the referenced issue
14:11
<annevk>
zcorpan: instead, the information on that is in the issue referenced from that issue: https://github.com/whatwg/fetch/issues/161#issuecomment-156414633
14:16
<mkwst>
annevk: FWIW, I've had adding `data:` support for Workers on my list of "things to do when I have free time" for a while now.
14:16
<annevk>
mkwst: for non-shared workers workers?
14:16
<mkwst>
like `data:` in the rest of Chrome, it wouldn't inherit an origin, so it would be a bit of a strangely sandboxed Worker.
14:16
<mkwst>
right. dedicated worker.
14:16
<annevk>
mkwst: oooh
14:16
<mkwst>
i won't be terribly sad if you kill it.
14:17
<annevk>
mkwst: so yeah, that'd be completely different from the specification
14:17
<mkwst>
yup!
14:17
<annevk>
mkwst: and so yeah, that's not what is being removed
14:17
<mkwst>
but we're already willfully violating that bit of the spec, so why not violate some more, right?
14:17
<mkwst>
ok, maybe I'm misunderstanding?
14:17
<annevk>
(in fact, data URL support was already removed, this is just removing some remnants)
14:17
<annevk>
mkwst: per the specification data URLs would be same-origin
14:17
<annevk>
(the old specification)
14:17
<mkwst>
annevk: I know.
14:18
<mkwst>
I know it's a bit annoying that Chrome's a special flower
14:18
<mkwst>
but I don't think we're planning on changing our `data:` handling.
14:18
<annevk>
Euhm, I don't care and I think we're trying to change Gecko
14:18
<mkwst>
ah.
14:18
mkwst
shuts up.
14:18
<annevk>
And most specifications reflect Chrome's policy
14:20
<zcorpan>
annevk: added a comment
14:20
<annevk>
zcorpan: where do you think the note should go?
14:22
<zcorpan>
annevk: how about after <li><p>Let <var>worker URL</var> be the resulting <span>absolute URL</span>.</p></li>
14:22
<annevk>
zcorpan: so you want two identical notes?
14:23
<zcorpan>
annevk: i don't follow
14:23
<annevk>
zcorpan: Worker and SharedWorker
14:24
<zcorpan>
oh. hmm
14:25
<annevk>
And this will go out of sync once we have those filesystem URLs (if ever) and such
14:27
<zcorpan>
yeah, two notes. the kinds of URLs we have doesn't change very often so i think it's worth it
14:31
<caitp>
it's almost that time of year when you fly to the keys and enjoy warmer-than-canada-in-january weather for a week or two. but there is no rest for the architects of the web
16:40
<MikeSmith>
nice https://code.google.com/p/chromium/issues/detail?id=303152#c22
18:54
<smaug____>
jgraham: most of the wpt tests are written by browser devs, right?
18:58
<smaug____>
(random wondering, why would anyone be sad about removing table sorting )
19:02
<wanderview>
jgraham: is there a way to attach the wpt --debugger arg to the child process in e10s mode?
19:03
<wanderview>
woops, wrong channel
19:11
<jgraham>
smaug____: I think most is very likely accurate, for a broad enough definition of "devs" (e.g. including QA)
19:45
<smaug____>
jgraham: yeah, I meant with the broader definition. I was just thinking how we could get help from also web devs
19:46
<smaug____>
right now I'd like to see tests for MessagePort
22:27
<bblfish>
annevk: I have succeeded in using Fetch now to authenticate cross originshttps://github.com/solid/solid-spec/issues/52#issuecomment-157519949
22:27
<bblfish>
oops. https://github.com/solid/solid-spec/issues/52#issuecomment-157519949