02:58
<MikeSmith>
annevk: http://stackoverflow.com/questions/37733163/cors-preflight-not-happening-consistently
02:59
<MikeSmith>
annevk: sounds like an implementation bug somewhere, but anyway just FYI if you have any clues
05:14
<annevk>
MikeSmith: commented
05:14
<MikeSmith>
thanks
05:24
<MikeSmith>
annevk: I guess I assumed the OP was talking about the same POST request made a different times, but seeing different behavior
05:24
<MikeSmith>
but maybe not
05:31
<rniwa>
MikeSmith: hi MikeSmith!
05:31
<rniwa>
annevk: hi annevk!
05:37
<annevk>
Hey rniwa, good evening 😊
05:42
<MikeSmith>
rniwa: hola
05:45
<rniwa>
annevk: glad we settled on getRootNode
05:45
<MikeSmith>
rniwa: question: Who do you reckon will probably end up doing the Service Worker implementation work for WebkKit? Maybe you?
05:45
<rniwa>
annevk: that git hub issue got super ugly LOL
05:45
<rniwa>
MikeSmith: definitely not me
05:45
<MikeSmith>
the main part of it I mean, or organizaing the work
05:45
<MikeSmith>
oh
05:45
<MikeSmith>
rniwa: wonder who else
05:45
<MikeSmith>
then
05:45
<rniwa>
MikeSmith: someone who knows the network stack
05:45
<MikeSmith>
ah yeah
05:45
<rniwa>
MikeSmith: like https://twitter.com/bradeeoh
05:46
<MikeSmith>
ah
05:47
<rniwa>
MikeSmith: we finally did some massive rewrite of the network stack this year but we've still got a long way...
05:48
<MikeSmith>
well
05:48
<MikeSmith>
you gonna rewrite large parts when you implement Service Workers
05:48
<MikeSmith>
I bet
05:48
<MikeSmith>
or at least need to touch large partts of it
05:53
<rniwa>
MikeSmith: yeah
06:09
<annevk>
rniwa: yeah, got resolved quickly after removal though 😊
06:09
<rniwa>
annevk: I guess we gotta thank Domenic for that ;)
06:09
<rniwa>
annevk: it looks like shadow DOM is getting into a good shape now
06:10
<rniwa>
annevk: adoption seems to be a big problem for custom elements though
06:10
<annevk>
MikeSmith: WebKit is doing Fetch refactoring first
06:10
<rniwa>
annevk: I'm of the opinion that it might be better to make adoption throw for now but that might be also tricky because some DOM APIs assume any node can be adopted :(
06:10
<annevk>
Which I've tried to advocate everyone to start with, but, you know
06:10
<MikeSmith>
annevk: oh
06:11
<annevk>
rniwa: yeah, that does not seem easy
06:12
<rniwa>
annevk: but spec'ing some semi-interoperable behavior seems super risky
06:12
<rniwa>
annevk: because i'm sure someone would start relying on that behavior with adopting from iframe, etc...
06:12
<annevk>
rniwa: also fails with the <template> pattern?
06:12
<rniwa>
annevk: something like that.
06:13
<rniwa>
annevk: so that's a big bummer
06:13
<annevk>
Hmm
06:13
<rniwa>
annevk: but custom elements don't get upgarded in regular template element's content anyway
06:13
<rniwa>
annevk: so that might be okay?
06:13
<rniwa>
or maybe we've changed that?
06:14
<annevk>
I think people expect copying the template into a shadow tree to not throw
06:14
<rniwa>
annevk: indeed
06:14
<rniwa>
annevk: but I think regular case would work because custom elements aren't upgraded in template contents
06:14
<rniwa>
annevk: the cloned nodes only get upgraded then they're inserted into a document
06:15
<rniwa>
annevk: so I don't think that use case is broken
06:15
<rniwa>
annevk: if I'm not mistaken
06:17
<annevk>
rniwa: yeah, that might be true
06:18
<annevk>
rniwa: same for importing from XHR and such
06:19
<rniwa>
annevk: right
06:19
<annevk>
rniwa: so the conditional would check cross-document and custom, and throw if so
06:19
<annevk>
Custom initialized*
06:19
<rniwa>
annevk: yeah, I think that might be acceptable until we get a better story for adoption
06:19
<rniwa>
annevk: adopting* builtin elements
06:21
<annevk>
giving a callback for self-cleanup seems like the only way out
06:22
<annevk>
Or requiring similar global state in both documents…
06:23
<annevk>
Ugh
06:24
<annevk>
I might blog about this
06:24
<annevk>
See what Twitter says
08:55
<tobie>
Ms2ger: I think you worked on a bikeshed port of the WebIDL spec.
08:56
<tobie>
Ms2ger: as I'm planning to work on precisely that, I thought there were pieces I might be able to recuperate, or at least knowledge of what problems you bumped into.
09:01
<tobie>
MikeSmith: I'm going to be triaging the WebIDL issue trackers. I'd want to close the bugzilla one and possibly migrate some or all of the outstanding issues to GitHub (afaik you have scripts for that).
09:01
<tobie>
MikeSmith: Would love to hear the pros and cons of migrating those and what your recommendations would be.
09:02
<annevk>
Only migrate if you fix or if you substantially improve the description of the issue
09:02
<annevk>
Migrations I've seen so far always require looking at the original bug
09:03
<tobie>
annevk: oh, that's an interesting strategy.
09:03
<annevk>
The copy-and-paste migrations go wrong and actually make things harder to follow
09:03
<tobie>
So that would be sort of like summarising and moving only ongoing issues to GH
09:04
<annevk>
Personally I just keep the bugs open, but there's probably some cut-off point where you should just migrate the remainder
09:05
<tobie>
I guess that makes sense.
09:06
<annevk>
https://www.npmjs.com/package/rdf-fetch hah
09:06
<annevk>
Can't escape 'm
09:07
<Ms2ger>
tobie, one thing I remember running into was that it doesn't support the grammar thingies
09:07
<tobie>
Ms2ger: I kind of suspected that was going to be an issue.
09:08
<tobie>
Did you run a manual transform or did you write some tools to do it?
09:08
<Ms2ger>
Manually with liberal search&replace
09:08
<tobie>
:D
09:10
<Ms2ger>
https://github.com/Ms2ger/webidl/tree/bs btw
09:10
<Ms2ger>
tobie, I also filed https://github.com/tabatkins/bikeshed/issues/542
09:11
<tobie>
ta
09:17
<Ms2ger>
tobie, fwiw, there's a webidl planning meeting at Mozilla's all hands meeting next week
09:19
<tobie>
Ms2ger: I'll DM you a snail mail address where Mozilla can send me my plane tickets.
09:19
<Ms2ger>
Where are you based nowadays?
09:19
<tobie>
Ms2ger: Geneva, Switzerland
09:20
<Ms2ger>
Maybe you can get there in annevk's carry-on :)
09:20
<tobie>
maybe
09:20
<tobie>
annevk? how big is your suitcase?
09:20
<annevk>
I've met tobie and that seems unlikely
09:21
<tobie>
My 6 month old son would fit, however.
09:21
<tobie>
He's got mad editing skilz
09:22
<tobie>
Not sure about his english, though.
09:22
<tobie>
More seriously; where's that thing going to be?
09:22
<annevk>
tobie: I'll happily pay for your flight
09:23
<annevk>
tobie: London, near Paddington iirc
09:23
<AutomatedTester>
tobie: London
09:23
<tobie>
Oh, I could totally do that.
09:23
<tobie>
When would that meeting be?
09:24
<annevk>
tobie: Mozilla is meeting all of next week, starting Tuesday
09:24
<tobie>
sure, but I just need to attend the WebIDL meetings
09:24
<annevk>
tobie: would be nice, so you can meet bz and heycam if you haven't before
09:25
<annevk>
tobie: right, I think that's scheduled for midday Wednesday
09:25
<tobie>
depending on the day--I could certainly make it.
09:25
<tobie>
OK, let me check and get back to you.
09:25
<tobie>
Think Moz could cover the ticket?
09:26
<annevk>
Probably, I can otherwise if it's not excessive
09:27
<tobie>
err--you check, I'll check with Domenic
09:28
<annevk>
Sure, left a message with the people in charge
09:28
<Ms2ger>
It's 11AM UTC+1 Wed
09:29
<tobie>
is UTC+1 the current london time?
09:29
<Ms2ger>
Yes
09:29
<tobie>
your offices are still in the same place I was in last time?
09:30
<annevk>
tobie: the meeting is in some hotel
09:30
<tobie>
oh
09:30
<Ms2ger>
I suspect http://www.hiltonlondonmet.com/
09:30
<Ms2ger>
We'll also need to get you a badge
09:30
<tobie>
https://wiki.mozilla.org/All_Hands/2016_London ?
09:31
<Ms2ger>
Yep
09:32
<annevk>
Ms2ger: that's the one, "Meeting Room 9", whatever that means, 12PM (though that conflicts so somewhere around that time...)
09:33
<Ms2ger>
https://mozillalondonallhands2016.sched.org/event/72q5/webidl-planning says 11AM, are you looking at a calendar in UTC+2?
09:34
<tobie>
sounds like I'm going to spend more on a steampunk outfit than on the plane ticket
09:35
<tobie>
You guys have FB logins for your all hand meetings? (speechless)
09:35
<Ms2ger>
The benefits of outsourcing
09:35
<annevk>
Ms2ger: oops, yes
09:36
<annevk>
Ms2ger: to be fair, that's the only real timezone
09:36
<Ms2ger>
I did the same yesterday while making a hard copy of my calendar
09:36
<annevk>
tobie: you can just create an account
09:37
<annevk>
Ms2ger: what annoys me a lot is that when I can get invited for events, it seems like the timezone information is dropped once I accept
09:37
<annevk>
Ms2ger: it's converted to local time and that's that
09:37
<Ms2ger>
Huh
09:38
<tobie>
Ok. Added this thing.
09:38
<tobie>
Should I plan to stay in town that evening and crash somewhere?
09:39
<tobie>
Or should I just fly back right away?
09:40
<annevk>
tobie: the evening before might be better
09:40
<annevk>
tobie: or both :-)
09:40
<tobie>
yeah--except that's a bit short notice to organize all the baby sitting required.
09:41
<annevk>
tobie: actually, it doesn't matter much, if you hang around on Wednesday we'll for sure be able to have dinner together and some other IDL/DOM folks
10:26
<jgraham>
Speaking of meetings
10:27
<jgraham>
Ms2ger: Any chance you want to go to TPAC?
10:27
annevk
wonders if MikeSmith is going to TPAC
10:28
<annevk>
rbyers has been convincing me I should go...
10:29
<jgraham>
YEah, rbyers seems to be trying to organise some tsting thing. Ms2ger should be there. Even if I have to get larsberg to manhandle him onto a plane ;)
10:30
<annevk>
jgraham: who do you plan on getting to get larsberg on a plane to do that?
10:30
<AutomatedTester>
jgraham: that shouldnt be difficult for larsberg :P
10:30
<AutomatedTester>
annevk: Jack?
10:30
<AutomatedTester>
the rest of the Servo team?
10:31
annevk
was not expecting a serious reply
10:32
<AutomatedTester>
you know better than to ask rhetorical questions with this group...
10:32
<jgraham>
annevk: I think larsberg is usually on a plane
10:32
<jgraham>
Although mostly flying back from Japan
10:33
<jgraham>
I'm sure he can schedule Tokyo->Brussels->Lisbon->Chicago somehow
11:04
<Ms2ger>
jgraham, when
11:06
<jgraham>
Ms2ger: https://www.w3.org/2016/09/TPAC/
11:27
<MikeSmith>
tobie: about the bug migration, what annevk said
11:27
<MikeSmith>
tobie: but also FYI I have never done a mass migration from bugzilla into github
11:28
<MikeSmith>
tobie: maybe dom or robin has, or plh
11:28
<tobie>
ok
11:28
<tobie>
MikeSmith: ok
11:29
<tobie>
MikeSmith: who do I need to talk to to give me a bit more privileges on the Bugzilla tracker?
11:29
<MikeSmith>
me
11:29
<MikeSmith>
I can go in now and set you up with whatever you need
11:30
<tobie>
MikeSmith: awesome.
11:30
<tobie>
No idea what I need precisely, but something so I can open/close issues, etc.
11:31
<MikeSmith>
tobie: btw just for the sake of comparison, there are still 151 bugs open bugs for HTML in bugzilla
11:31
<MikeSmith>
https://www.w3.org/Bugs/Public/buglist.cgi?component=HTML&list_id=63854&product=WHATWG&resolution=---
11:31
<tobie>
think I'm using my gmail account on this (tobie.langel⊙gc)
11:31
<tobie>
oh wow
11:31
<MikeSmith>
down from 350 or someting when it was first moved to github
11:32
<MikeSmith>
those 151 bugs are all pretty tough ones
11:32
<MikeSmith>
the low-hanging fruit was dealt with a long time ago, then the medium-hanging fruit
11:32
<tobie>
I see
11:33
<MikeSmith>
but in parallel a ton of work has been done at https://github.com/whatwg/html/issues and https://github.com/whatwg/html/pulls
11:33
<MikeSmith>
more than 700 PRs and more than 650 issues
11:34
<MikeSmith>
(this is all for the source, not the fork)
11:36
<MikeSmith>
tobie: OK just gave you editcomponents editkeywords editclassifications perms
11:37
<MikeSmith>
there is no more that is give-able without making you an admin
11:37
<MikeSmith>
which I can do if really needed
11:39
<MikeSmith>
annevk: will be at TPAC
11:39
<MikeSmith>
in full effect
11:53
<Ms2ger>
MikeSmith, I guess that's reason enough to come
11:58
<MikeSmith>
Ms2ger: yeah I know people like the play the odds on trying to most accurately pick the time during each meeting when I nod off and then suddenly snap back awake while making some weird gurgling sound
12:07
<ondras>
so, looking for an advice re. web app security
12:07
<ondras>
initially, we passed our (config) values to JS via a server-side template: <script>var CONF = {{somedata}}</script>
12:07
<ondras>
the we decided to use CSP without unsafe-inline
12:07
<ondras>
so we moved this to a .js file
12:08
<ondras>
<script src="conf.js"></script>, conf.js: var CONF = {{somedata}}
12:08
<ondras>
but it turns out that somedata is sensitive, cookie-based auth
12:08
<ondras>
so an attacker can insert <script src="ourdomain/conf.js"></script>
12:08
<ondras>
what are my options here?
12:08
<ondras>
fetching conf via XHR, Referer check, anything else?
12:14
<ondras>
annevk: ^
12:17
<annevk>
ondras: XHR/fetch
12:18
<annevk>
ondras: in the future maybe first-party cookies, but I'm not entirely sure what the processing model of those is going to be
12:19
<annevk>
ondras: that's an interesting little story you got there though
12:19
<annevk>
ondras: note that for a slightly different reason this is also a bad API; this is similar to JSONP which some sites use to talk to each other
12:19
<annevk>
ondras: basically allowing the other site to execute code in your origin
12:20
<annevk>
ondras: basically whenever you have data to exchange, put it behind some HTTP API
12:21
<ondras>
right, I am pretty familiar with JSONP
12:21
<ondras>
moving this stuff to .js was a straightforward way to do CSP
12:21
<ondras>
I guess nobody thought about potential security issues with this approach
12:22
<ondras>
annevk: thanks for consultation and your time! What do you thing about that Referer check as a fast way to fix this?
12:22
<annevk>
ondras: what would you do when Referer is omitted?
12:22
<ondras>
403
12:22
<ondras>
or similar
12:22
<ondras>
401
12:22
<ondras>
..
12:23
<annevk>
ondras: coupled with the cookie that might be sufficient
12:23
<annevk>
ondras: status code doesn't matter so much, as long as you don't include the content
12:23
<ondras>
right
12:23
<ondras>
the cookie is going to stay there
12:23
<annevk>
ondras: but some software on the user's computer might strip Referer
12:23
<ondras>
I am just not sure whether all regular UAs sned the Referer
12:23
<ondras>
hm, do we have any numbers on that?
12:23
<annevk>
ondras: Google had some numbers on that (5% iirc), not sure if it affects HTTPS too
12:24
<annevk>
ondras: that's in part why CORS has Origin
12:24
<ondras>
annevk: the whole site is https only
12:24
<annevk>
Although Origin and Referer can be different too... hmm
12:56
<MikeSmith>
zcorpan: I based together something for the comment thing, and pushed it to https://checker.html5.org/
12:56
<MikeSmith>
zcorpan: I have done almost no testing of it
12:56
<MikeSmith>
if we are going to ever really land it we will need test cases
12:57
<MikeSmith>
in the mean time please try it and see what I missed
12:57
<MikeSmith>
beacuse I’m sure I did miss something
12:57
<MikeSmith>
it handles the new error for <!--
12:57
<MikeSmith>
or intends to
12:57
<MikeSmith>
diff of the parser change is at https://github.com/validator/htmlparser/commit/f0b12a2769734ddf716d7fa4f54f2da90a4dd6ef
12:58
MikeSmith
with that steps away for a couple hours
12:58
<zcorpan>
MikeSmith: awesome, will check. thanks
12:58
<MikeSmith>
cheers
13:27
zcorpan
commented on the diff
13:32
<zcorpan>
MikeSmith: in what form do you prefer to have test cases? html5lib tokenizer tests?
13:33
zcorpan
gotta go, will read logs
14:18
<annevk>
Hmm, so navigation in the HTML Standard is broken...
14:18
<annevk>
manishearth: e.g., as you likely have discovered too, if you get a 204, even as the result of a redirect, the unload process will not have started yet
14:19
<annevk>
manishearth: unloading starts after you get a response (all HTTP headers are in)...
14:19
<annevk>
How can this have been wrong for so long?
14:19
<manishearth>
annevk: nobody implements the spec word-to-word :)
14:19
<manishearth>
except servo
14:20
<jgraham>
*including servo
14:20
<Manishearth>
well, yeah
14:20
<annevk>
Servo is the hero standards need, but they don't deserve it
14:20
<Manishearth>
but we try to get our code matching the spec as much as possible
14:21
<Manishearth>
AFAICT other browsers read the spec, get an idea of what's necessary, and then implement it independently, perhaps glancing at the spec
14:21
<Manishearth>
at least, that's the vibe I've gotten from gecko code. but I haven't looked at much
14:21
<Manishearth>
we deviate from the spec when we don't implement a feature or if we feel that a set of steps is equivalent
14:21
<Manishearth>
but this is small scale
14:21
<Manishearth>
(not the "don't have the feature" thing)
14:22
<Manishearth>
but the nice thing is that it's very easy to find bugs when your code is like this. either in servo or in the spec :)
14:23
<annevk>
The amount of spec that needs to be rewritten for navigation appears to be most of it
14:24
<annevk>
But I'm slowly getting a sense of what it needs to do, unfortunately another week of distraction is coming up
14:25
<annevk>
The behavior in browsers is also far more logical... Wait for a final response, than unload if necessary
14:27
<Manishearth>
annevk: :(
14:29
<annevk>
Manishearth: sometime Europe's summer this will all be in a much better state, navigation and allocating documents
14:29
<annevk>
Unless it ends up being too hard, but so far it seems tractable, just taking loads of time
14:30
<Manishearth>
ah
14:30
<annevk>
I guess there's also the caveat that my manager has some other priorities, but that seems unlikely
14:32
<jgraham>
I'm not sure what browsers do for navigation is *that* sane
14:32
<jgraham>
Depending on what you mean by navigation
14:33
<jgraham>
e.g. the stuff about how documents don't end up in the session history if they get unloaded too eaerly
14:33
<jgraham>
*early
14:40
<annevk>
Manishearth: if you're still curious, redirects do have an effect with fragments
14:40
<annevk>
Manishearth: so test.html that navigates to redirect-to-test.html#x and thus ends up being test.html#x will unload
14:41
<Manishearth>
nice
14:41
<annevk>
Manishearth: so that whole thing of jumping back to the fragments step after redirects...
14:42
<Manishearth>
oh I see how this can get complicated :)
14:42
<annevk>
tobie: not sure if you're still around, but see various PMs
14:43
<annevk>
jgraham: is that about the algorithm maturing?
14:44
<annevk>
jgraham: I've mostly been studying the "basics" thus far
14:44
<jgraham>
annevk: I don't recall if it's in the spec or not, but I remember running into interop problems around what happened to the history if you did document.open during load or similar
14:45
<jgraham>
This was some time ago though
15:39
jgraham
grumbles at Travis (the person, not the CI tool)
16:48
mathiasbynens
spots annevk’s Twitter bio
16:49
<annevk>
mathiasbynens: closest to a business card, which I don’t have
17:51
<tobie>
MikeSmith: ty
17:54
<tobie>
annevk: BEARD!!
18:39
<wanderview>
tobie: that was my thought as well