/irc-logs / freenode / #whatwg / 2015-07-27 / end

Options:

# Session Start: Mon Jul 27 00:00:00 2015
# Session Ident: #whatwg
# [00:00] * Quits: sangwhan (~sid23@tor-exit.echelon.nsa.network) (Remote host closed the connection)
# [00:02] * Joins: sangwhan (~sid23@tor-exit.echelon.nsa.network)
# [00:02] * Quits: sangwhan (~sid23@tor-exit.echelon.nsa.network) (Remote host closed the connection)
# [00:03] * Joins: rxgx (uid22483@gateway/web/irccloud.com/x-pytppiwaryjorcip)
# [00:03] * Joins: annevk (~annevk@195.12.41.182)
# [00:04] * Joins: sangwhan (~sid23@tor-exit.echelon.nsa.network)
# [00:08] * Quits: annevk (~annevk@195.12.41.182) (Ping timeout: 240 seconds)
# [00:08] * Quits: weinig (~weinig@166.170.37.47) (Quit: weinig)
# [00:12] * Joins: strugee (~strugee@2602:d8:a048:e600:2247:47ff:fe82:d58c)
# [00:13] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
# [00:16] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [00:19] * Quits: bin_005 (~ctlM@80.83.238.41) (Read error: Connection reset by peer)
# [00:21] * Quits: ttepasse (~ttepasse@ip-178-200-61-79.hsi07.unitymediagroup.de) (Quit: Textual IRC Client: www.textualapp.com)
# [00:40] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [00:44] <TabAtkins> Domenic: The example code in 4.2.2 of the promises guide is actually super confusing.
# [00:44] <TabAtkins> "Run the following in parallel" suggests that the two substeps are meant to race each other in parallel, when that's exactly opposite.
# [00:45] <TabAtkins> I thought the suggestion was to put the async section at the end, with an explicit "return foo, and continue the rest of this algorithm async"
# [00:47] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
# [00:54] * Quits: Maurice` (~copyman@unaffiliated/maurice)
# [01:00] * Joins: satazor (~satazor@37.189.179.118)
# [01:02] * Quits: roc (~chatzilla@121.98.89.122) (Ping timeout: 255 seconds)
# [01:04] * Joins: annevk (~annevk@195.12.41.182)
# [01:04] * Quits: igoroliveira (uid20755@gateway/web/irccloud.com/x-gfcygiumhzaopxwc) (Quit: Connection closed for inactivity)
# [01:07] * Joins: weinig (~weinig@c-50-131-222-145.hsd1.ca.comcast.net)
# [01:09] * Quits: annevk (~annevk@195.12.41.182) (Ping timeout: 255 seconds)
# [01:14] * Quits: capella-s3 (~yaaic@cpe-24-59-243-39.twcny.res.rr.com) (Ping timeout: 246 seconds)
# [01:15] * Quits: dustinm` (~dustinm@105.ip-167-114-152.net) (Ping timeout: 264 seconds)
# [01:16] * Joins: capella-s3 (~yaaic@cpe-24-59-243-39.twcny.res.rr.com)
# [01:21] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-vsondwbefbjlegpa)
# [01:21] * Joins: dustinm` (~dustinm@2607:5300:100:200::160d)
# [01:31] * Joins: encryptd_fractal (~encryptd_@c-24-7-238-5.hsd1.mn.comcast.net)
# [01:41] * Quits: frivoal_ (~frivoal@por44-h01-176-147-244-60.dsl.sta.abo.bbox.fr) (Remote host closed the connection)
# [01:41] * Joins: frivoal (~frivoal@por44-h01-176-147-244-60.dsl.sta.abo.bbox.fr)
# [01:42] * Quits: frivoal (~frivoal@por44-h01-176-147-244-60.dsl.sta.abo.bbox.fr) (Remote host closed the connection)
# [01:47] * Quits: Ms2ger (~Ms2ger@91.180.189.254) (Quit: nn)
# [01:55] * Joins: roc (~chatzilla@2400:e780:801:224:2677:3ff:fece:dc64)
# [01:58] * Quits: encryptd_fractal (~encryptd_@c-24-7-238-5.hsd1.mn.comcast.net) (Remote host closed the connection)
# [02:06] * Quits: smaug____ (~chatzilla@a91-154-44-165.elisa-laajakaista.fi) (Ping timeout: 260 seconds)
# [02:07] * Quits: capella-s3 (~yaaic@cpe-24-59-243-39.twcny.res.rr.com) (Quit: Talk atcha later)
# [02:11] * Quits: tav (~tav`@host31-52-143-119.range31-52.btcentralplus.com) (Quit: tav)
# [02:12] * Joins: tav (~tav`@host31-52-143-119.range31-52.btcentralplus.com)
# [02:13] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
# [02:17] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [02:22] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 260 seconds)
# [02:41] * Joins: encryptd_fractal (~encryptd_@c-24-7-238-5.hsd1.mn.comcast.net)
# [02:47] * Quits: satazor (~satazor@37.189.179.118) (Remote host closed the connection)
# [02:47] * Quits: encryptd_fractal (~encryptd_@c-24-7-238-5.hsd1.mn.comcast.net) (Remote host closed the connection)
# [02:49] * Quits: weinig (~weinig@c-50-131-222-145.hsd1.ca.comcast.net) (Quit: weinig)
# [02:49] * Joins: satazor (~satazor@37.189.179.118)
# [02:49] * Quits: satazor (~satazor@37.189.179.118) (Remote host closed the connection)
# [02:52] * Joins: encryptd_fractal (~encryptd_@2601:449:8100:cad9:1512:ca72:1ebe:e46a)
# [02:52] * Joins: annevk (~annevk@195.12.41.182)
# [02:56] * Joins: jensnockert (~jensnocke@84.219.248.21)
# [02:57] * Quits: annevk (~annevk@195.12.41.182) (Ping timeout: 240 seconds)
# [02:57] * Quits: rxgx (uid22483@gateway/web/irccloud.com/x-pytppiwaryjorcip) (Quit: Connection closed for inactivity)
# [03:00] * Quits: encryptd_fractal (~encryptd_@2601:449:8100:cad9:1512:ca72:1ebe:e46a) (Remote host closed the connection)
# [03:01] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 250 seconds)
# [03:03] * Joins: satazor (~satazor@94.60.78.118)
# [03:06] * Quits: plutoniix (~plutoniix@node-m9q.pool-101-51.dynamic.totbb.net) (Quit: จรลี จรลา)
# [03:08] <MikeSmith> Domenic, for botie, I think you currently need to use "inform" instead of "tell" (I'll try to hack my copy of its source to add support for "tell", or maybe it's already been added upstream and I just need to pull it)
# [03:17] * Joins: caitp (~green@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [03:17] * Quits: JoWie (uid93456@gateway/web/irccloud.com/x-nhtrhfpmnxjtkjvq) (Quit: Connection closed for inactivity)
# [03:19] * Quits: CvP (~CvP@203.76.123.238) (Ping timeout: 260 seconds)
# [03:23] * Joins: tripu (~tripu@2001:200:0:8805:b86f:934f:4e8f:a72e)
# [03:44] * Quits: tripu (~tripu@2001:200:0:8805:b86f:934f:4e8f:a72e) (Ping timeout: 246 seconds)
# [03:46] * Joins: tripu (~tripu@2001:200:0:8805:b86f:934f:4e8f:a72e)
# [03:46] * Quits: caitp (~green@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Read error: Connection reset by peer)
# [03:47] * Joins: caitp (~green@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [03:47] * Joins: ohaibbq (~ohaibbq@2601:643:8100:9bc4:5dad:3624:360a:d4ac)
# [03:49] * Quits: caitp (~green@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Read error: Connection reset by peer)
# [03:49] * Joins: caitp- (~green@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [03:53] * Joins: annevk (~annevk@195.12.41.182)
# [03:53] * Quits: satazor (~satazor@94.60.78.118) (Remote host closed the connection)
# [03:54] * Quits: igoroliveira (uid20755@gateway/web/irccloud.com/x-vsondwbefbjlegpa) (Quit: Connection closed for inactivity)
# [03:55] * Quits: caitp- (~green@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Read error: Connection reset by peer)
# [03:55] * Joins: caitp (~green@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [03:57] * Quits: annevk (~annevk@195.12.41.182) (Ping timeout: 252 seconds)
# [04:17] * Joins: Goplat (~goplat@reactos/developer/Goplat)
# [04:22] * Joins: weinig (~weinig@c-50-131-222-145.hsd1.ca.comcast.net)
# [04:22] * Quits: seventh (seventh@199.48.241.63) (Remote host closed the connection)
# [04:54] * Joins: annevk (~annevk@195.12.41.182)
# [04:55] * Quits: tripu (~tripu@2001:200:0:8805:b86f:934f:4e8f:a72e) (Ping timeout: 244 seconds)
# [04:56] * Joins: tripu (~tripu@2001:200:0:8805:b86f:934f:4e8f:a72e)
# [04:57] * Joins: jensnockert (~jensnocke@84.219.248.21)
# [04:58] * Quits: annevk (~annevk@195.12.41.182) (Ping timeout: 250 seconds)
# [04:59] * Joins: psy_ (~psy@43.224.156.119)
# [04:59] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [04:59] * Quits: psy_ (~psy@43.224.156.119) (Client Quit)
# [04:59] * Joins: psy_ (~psy@43.224.156.119)
# [05:01] * Joins: plutoniix (~plutoniix@ppp-124-122-112-12.revip2.asianet.co.th)
# [05:02] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 264 seconds)
# [05:13] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Read error: Connection reset by peer)
# [05:18] * Joins: dbaron (~dbaron@173-228-85-118.dsl.dynamic.fusionbroadband.com)
# [05:18] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [05:23] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 265 seconds)
# [05:27] * Quits: boogyman (~mrj@pdpc/supporter/professional/boogyman) (Read error: Connection reset by peer)
# [05:28] * Joins: boogyman (~mrj@d-65-175-179-47.cpe.metrocast.net)
# [05:28] * Quits: boogyman (~mrj@d-65-175-179-47.cpe.metrocast.net) (Changing host)
# [05:28] * Joins: boogyman (~mrj@pdpc/supporter/professional/boogyman)
# [05:32] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [05:46] * Joins: howdoi_ (uid224@gateway/web/irccloud.com/x-gaivuhlzseyasoro)
# [05:54] * Joins: tantek (~tantek@67.221.169.243)
# [06:00] * Quits: tantek (~tantek@67.221.169.243) (Ping timeout: 264 seconds)
# [06:09] * Joins: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net)
# [06:09] * Quits: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net) (Client Quit)
# [06:14] * Joins: CvP (~CvP@203.76.123.238)
# [06:23] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Read error: Connection reset by peer)
# [06:24] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [06:28] * Joins: rxgx (uid22483@gateway/web/irccloud.com/x-enyibgvaratoeyib)
# [06:29] * Quits: weinig (~weinig@c-50-131-222-145.hsd1.ca.comcast.net) (Quit: weinig)
# [06:38] * Joins: tantek (~tantek@70-36-139-190.dsl.dynamic.fusionbroadband.com)
# [06:42] * Joins: annevk (~annevk@195.12.41.182)
# [06:44] * daurnimator is now known as [daurnimator]
# [06:46] * Quits: botie (~i-bot@sideshowbarker.net) (Quit: regrouping; bbiab)
# [06:46] * Quits: annevk (~annevk@195.12.41.182) (Ping timeout: 256 seconds)
# [06:47] * Joins: KevinMarks_ (~yaaic@2607:fb90:2c2c:e357:5707:f5b8:4c2b:ddc8)
# [06:49] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
# [06:49] * Joins: botie (~i-bot@sideshowbarker.net)
# [06:50] <MikeSmith> botie: tell Domenic botie now understands "tell"
# [06:50] <botie> will do
# [06:56] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [06:58] * Joins: jensnockert (~jensnocke@84.219.248.21)
# [07:01] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
# [07:03] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 240 seconds)
# [07:11] * Quits: tripu (~tripu@2001:200:0:8805:b86f:934f:4e8f:a72e) (Ping timeout: 246 seconds)
# [07:15] * Joins: tripu (~tripu@2001:200:0:8805:b86f:934f:4e8f:a72e)
# [07:18] * Joins: annevk (~annevk@195.12.41.182)
# [07:23] * Quits: tantek (~tantek@70-36-139-190.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
# [07:29] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [07:29] <annevk> TabAtkins: https://fetch.spec.whatwg.org/#dom-global-fetch uses that style
# [07:30] <annevk> TabAtkins: https://storage.spec.whatwg.org/#dom-storagemanager-requestpersistent does too
# [07:30] <annevk> TabAtkins: given that "in parallel" is defined I don't think it matters much
# [07:32] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [07:35] * Quits: roc (~chatzilla@2400:e780:801:224:2677:3ff:fece:dc64) (Ping timeout: 244 seconds)
# [07:41] <annevk> Domenic: I can't assign issues to TabAtkins so I don't think that works
# [07:41] <annevk> Domenic: we'd have to actually give contributors access to a set of repositories for that
# [07:46] * Quits: tripu (~tripu@2001:200:0:8805:b86f:934f:4e8f:a72e) (Ping timeout: 246 seconds)
# [07:46] * Joins: tantek (~tantek@70-36-139-190.dsl.dynamic.fusionbroadband.com)
# [07:46] * Joins: xiinotulp (~plutoniix@ppp-124-122-168-180.revip2.asianet.co.th)
# [07:47] * Quits: rego_ (~rego@66.193.27.77.dynamic.mundo-r.com) (Remote host closed the connection)
# [07:47] * Joins: rego (~rego@66.193.27.77.dynamic.mundo-r.com)
# [07:50] * Joins: tripu (~tripu@2001:200:0:8805:b86f:934f:4e8f:a72e)
# [07:50] * Quits: plutoniix (~plutoniix@ppp-124-122-112-12.revip2.asianet.co.th) (Ping timeout: 244 seconds)
# [07:51] <TabAtkins> annevk: Of course it matters! It doesn't matter if there's a link to the full meaning if the plain English reads completely wrong.
# [07:51] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [07:51] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [07:54] * Quits: rwaldron (rwaldron@gateway/shell/jquery.com/x-htsdxacjtilaqewg) (Ping timeout: 246 seconds)
# [07:55] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [07:55] * Joins: rwaldron (rwaldron@gateway/shell/jquery.com/x-jlhsutojwjunbjbv)
# [07:57] * Quits: KevinMarks_ (~yaaic@2607:fb90:2c2c:e357:5707:f5b8:4c2b:ddc8) (Ping timeout: 244 seconds)
# [08:00] <annevk> TabAtkins: yeah, I guess we disagree on the plain English reading wrong
# [08:03] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [08:05] * xiinotulp is now known as plutoniix
# [08:08] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [08:09] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
# [08:11] <TabAtkins> At least in my ideolect, "Do the following Xs in parallel" means that they'll all execute at the same time. (Not that they'll run in series, in parallel with the surrounding context.)
# [08:12] * Quits: ohaibbq (~ohaibbq@2601:643:8100:9bc4:5dad:3624:360a:d4ac) (Quit: Leaving...)
# [08:13] <annevk> In that case "Run the remaining Xs in parallel" would mean the same thing
# [08:13] <annevk> So neither would be clear with such an interpretation
# [08:19] <TabAtkins> Which is why I'm not suggesting either. There's another phrasing, used in Font Loading, which isn't possible to misunderstand.
# [08:25] <annevk> Well, except it doesn't define "asynchronously" and we've had a bunch of concerns raised over the word "asynchronous" which is why it's "in parallel" (and is somewhat defined) now
# [08:25] * Joins: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net)
# [08:27] <annevk> You also update internal slots from asynchronous thread which seems all kinds of wrong
# [08:27] <annevk> an*
# [08:44] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: The deeper I go / the deeper I go / green mountains - Santoka)
# [08:47] <annevk> philipj: I was thinking, we could also restrict requestFullscreen() on <iframe> by doing an inclusive ancestor check for <iframe> in the ready check, but I guess now Microsoft ships an "iframe fullscreen flag" we should just go with that
# [08:48] <annevk> philipj: also, is it a problem the specification does not deal with <frame>, <object>, and <embed> in some way?
# [08:48] <annevk> I guess those don't support allowfullscreen
# [08:57] * Quits: rxgx (uid22483@gateway/web/irccloud.com/x-enyibgvaratoeyib) (Quit: Connection closed for inactivity)
# [08:58] * Quits: dbaron (~dbaron@173-228-85-118.dsl.dynamic.fusionbroadband.com) (Ping timeout: 244 seconds)
# [08:59] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
# [08:59] * Joins: jensnockert (~jensnocke@84.219.248.21)
# [09:00] * Quits: mpt (~mpt@canonical/mpt) (Remote host closed the connection)
# [09:01] * Quits: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net) (Quit: sicking)
# [09:02] * Joins: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net)
# [09:02] * Joins: roc (~chatzilla@121.98.95.75)
# [09:04] * Joins: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek)
# [09:04] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 255 seconds)
# [09:06] * Quits: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net) (Client Quit)
# [09:07] * Joins: mpt (mpt@canonical/mpt)
# [09:08] <philipj> annevk: I would be quite happy just ignoring the iframe.requestFullscreen() followed by elementInIframe.requestFullscreen() problem
# [09:08] <philipj> I do wonder if it's been an issue in reality
# [09:08] <annevk> Unless my fix is wrong, it does seem relatively easy to fix
# [09:09] <philipj> annevk: I don't think <frame> and friends matter, there was support in WebKit/Blink that was removed,
# [09:10] <philipj> I have seen one bug report where the reason fullscreen didn't work was because of <frame>, though
# [09:10] <philipj> annevk: fixing it with a flag is fine too, since apparently Microsoft was concerned enough to invent their own solution without telling anyone
# [09:12] <annevk> philipj: did you ever look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=16502?
# [09:13] <annevk> philipj: yeah, my thinking was that since they went through the trouble of implementing that and telling us about it (somewhat belatedly) it's okay for us to accept the cost this one time
# [09:13] * Joins: espadrine_ (~tyl@dan75-7-88-166-187-54.fbx.proxad.net)
# [09:13] <philipj> annevk: I have seen that bug, but am not sure what to make of it.
# [09:13] <annevk> philipj: although if they keep doing it that way I won't be as nice about it I think
# [09:14] <annevk> philipj: I guess I'll wait to see if the Presentation API folks have anything to say
# [09:14] <philipj> annevk: Trying to close all Bugzilla bugs are you?
# [09:14] <annevk> Yeah, was thinking of marking the other one MOVED
# [09:15] <annevk> but I guess I can wait a little longer, there's no particular rush
# [09:15] <philipj> Yep
# [09:15] * Quits: jochen__ (jochen@nat/google/x-xtvspjidwztscutf) (Read error: Connection reset by peer)
# [09:18] * Joins: alrra (uid62345@gateway/web/irccloud.com/x-yhieazpsdbzeifsb)
# [09:18] <philipj> annevk: it might interest you to know that there's something weird going on with optional arguments and addEventListener()
# [09:19] <philipj> All of the arguments are optional in Blink, an attempt to fix it a long time ago was reverted due to something breaking, and now the use counters don't look very promising.
# [09:19] <philipj> I don't suppose you've seen any reports in Gecko about this?
# [09:22] <annevk> philipj: nope
# [09:25] * Joins: calvaris (~calvaris@fanzine.igalia.com)
# [09:26] * Joins: karlcow (~karl@nerval.la-grange.net)
# [09:31] * Joins: 7GHAAS5SA (~czerasz@acug45.neoplus.adsl.tpnet.pl)
# [09:31] * Joins: 7JTAACPOS (~czerasz@acug45.neoplus.adsl.tpnet.pl)
# [09:31] * Joins: frivoal (~frivoal@por44-h01-176-147-244-60.dsl.sta.abo.bbox.fr)
# [09:32] * Quits: 7GHAAS5SA (~czerasz@acug45.neoplus.adsl.tpnet.pl) (Max SendQ exceeded)
# [09:32] * Joins: czerasz2 (~czerasz@acug45.neoplus.adsl.tpnet.pl)
# [09:35] * Quits: frivoal (~frivoal@por44-h01-176-147-244-60.dsl.sta.abo.bbox.fr) (Ping timeout: 252 seconds)
# [09:41] * Quits: Lachy (~Lachy@cm-84.215.179.176.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [09:48] * Joins: Ms2ger (~Ms2ger@91.180.189.254)
# [09:49] * Joins: JoWie (uid93456@gateway/web/irccloud.com/x-efyditranebkehat)
# [09:52] * Quits: czerasz2 (~czerasz@acug45.neoplus.adsl.tpnet.pl) (Ping timeout: 250 seconds)
# [09:52] * Quits: 7JTAACPOS (~czerasz@acug45.neoplus.adsl.tpnet.pl) (Ping timeout: 260 seconds)
# [10:02] * Quits: dshwang__ (~dshwang@134.134.139.72) (Quit: Leaving)
# [10:02] * Joins: dshwang (~dshwang@192.55.54.40)
# [10:03] <MikeSmith> philipj: a servo guy who was trying to run the wpt DOM ChildeNode tests today was wondering why https://codereview.chromium.org/1234813003/ was reverted
# [10:03] <MikeSmith> (the related wpt tests came from blink upstream, from that changeset)
# [10:04] <MikeSmith> that review cites https://code.google.com/p/chromium/issues/detail?id=509461
# [10:04] <Ms2ger> @@unscopeables?
# [10:04] <MikeSmith> philipj: but I get a 403 trying to view that bug so I assume it's a security issue
# [10:06] <philipj> MikeSmith: it introduced a crash which is being fixed, not a problem with the spec if that's the concern
# [10:07] <MikeSmith> philipj: ah yeah maybe he had been wondering if it was spec issue
# [10:08] <MikeSmith> anyway thanksーI'll pass on the info if/when I chat with him
# [10:08] <philipj> MikeSmith: np
# [10:09] * Quits: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr) (Excess Flood)
# [10:10] * Joins: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr)
# [10:12] <frewsxcv> Thanks for the info philipj
# [10:12] * frewsxcv is the 'servo guy'
# [10:13] <philipj> frewsxcv: are Nodes refcounted in Servo or what's the general story for keeping them alive across an event dispatch that may run GC?
# [10:13] <Ms2ger> Garbage collection!
# [10:14] <Ms2ger> https://github.com/servo/servo/blob/7235500db6778371abe1d1f727a6d0b24205d5c5/components/script/docs/JS-Servos-only-GC.md
# [10:15] <Ms2ger> Not entirely up-to-date (which I should fix), but fairly
# [10:15] <philipj> Then you will not have the particular crash we did :)
# [10:16] <Ms2ger> We should be entirely safe :)
# [10:16] <philipj> I presume that having the equivalent of a this pointer on the stack will also protect it from GC?
# [10:16] <Ms2ger> Were those mutation events?
# [10:16] <frewsxcv> Last words by every software developer...
# [10:16] <Ms2ger> Yeah
# [10:16] <philipj> Ms2ger: I don't remember, but seems likely.
# [10:17] <philipj> mutation events FTW
# [10:17] <Ms2ger> Fortunately we don't have those either :)
# [10:18] <philipj> Ms2ger: Feel like removing them in Gecko?
# [10:18] <MikeSmith> wow https://github.com/servo/servo/blob/7235500db6778371abe1d1f727a6d0b24205d5c5/components/script/docs/JS-Servos-only-GC.md is nice stuff
# [10:18] <philipj> UseCounter says no: https://www.chromestatus.com/metrics/feature/timeline/popularity/144
# [10:18] <Ms2ger> Ohgodno
# [10:20] <MikeSmith> sad
# [10:20] <MikeSmith> how high those numbers are stil
# [10:21] <philipj> That's the highest of them, but even the lowest isn't negligible: https://www.chromestatus.com/metrics/feature/timeline/popularity/146
# [10:24] <MikeSmith> doubly sad
# [10:24] <MikeSmith> wait but that's below 0.03 at least
# [10:26] <MikeSmith> also JS-Servos-only-GC.md is nicely worded
# [10:26] <MikeSmith> Ms2ger: who wrote that?
# [10:27] <MikeSmith> "Josh Matthews and Keegan McAllister"
# [10:27] <Ms2ger> Yep
# [10:27] <Ms2ger> With a little editing from me, but mostly them
# [10:27] <MikeSmith> ok
# [10:28] <MikeSmith> good on you as well then
# [10:29] <Ms2ger> Maybe I should finish it toay
# [10:35] * Joins: Lachy (~Lachy@213.166.174.2)
# [10:36] * Joins: g4 (~g4@unaffiliated/gormer)
# [10:37] * Quits: espadrine_ (~tyl@dan75-7-88-166-187-54.fbx.proxad.net) (Ping timeout: 256 seconds)
# [10:41] <hugoh> window move up
# [10:42] * Quits: tantek (~tantek@70-36-139-190.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
# [10:42] <Ms2ger> Hey! Where'd my window go?
# [10:43] <hugoh> sorry! forgot the /
# [11:00] * Joins: jensnockert (~jensnocke@84.219.248.21)
# [11:05] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 250 seconds)
# [11:08] * Joins: smaug____ (~chatzilla@a91-154-44-165.elisa-laajakaista.fi)
# [11:15] * Joins: espadrine_ (~tyl@213.152.18.159)
# [11:25] * Joins: ttepasse (~ttepasse@ip-178-200-61-79.hsi07.unitymediagroup.de)
# [11:35] * Joins: adactio (~adactio@212.42.170.121)
# [11:36] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: The deeper I go / the deeper I go / green mountains - Santoka)
# [11:45] * Quits: espadrine_ (~tyl@213.152.18.159) (Ping timeout: 252 seconds)
# [11:46] * Quits: tripu (~tripu@2001:200:0:8805:b86f:934f:4e8f:a72e) (Ping timeout: 246 seconds)
# [11:51] * Joins: frivoal (~frivoal@por44-h01-176-147-244-60.dsl.sta.abo.bbox.fr)
# [11:55] * Joins: Maurice` (copyman@unaffiliated/maurice)
# [12:00] <annevk> philipj: we might be able to change mutation event timing
# [12:00] <annevk> philipj: e.g. give them the same timing as custom element callbacks
# [12:01] * Quits: sarri (~sari@unaffiliated/sarri) (Ping timeout: 256 seconds)
# [12:04] * Joins: sarri (~sari@unaffiliated/sarri)
# [12:05] * Joins: espadrine_ (~tyl@213.152.18.159)
# [12:07] * [daurnimator] is now known as daurnimator
# [12:14] * Joins: satazor (~satazor@37.189.179.118)
# [12:17] * Joins: ttepasse_ (~ttepasse@ip-178-200-61-79.hsi07.unitymediagroup.de)
# [12:17] * Joins: caitp- (~green@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [12:18] * Joins: yhirano__ (uid40668@gateway/web/irccloud.com/x-hlghdiadusdwgjrn)
# [12:18] <smaug____> except DOMNodeRemoved
# [12:18] * Joins: bterlson_ (sid23757@gateway/web/irccloud.com/x-xidxxhplslyzxsnr)
# [12:19] * Joins: dmurph_ (sid42525@gateway/web/irccloud.com/x-tgmulyfujxwjyvbf)
# [12:19] * Joins: Sebmaster_ (sid80609@gateway/web/irccloud.com/x-pnhvcrbzztzemzdo)
# [12:19] * Joins: cfq_ (sid18398@gateway/web/irccloud.com/x-frypssynmpughpox)
# [12:19] <annevk> smaug____: what do you mean?
# [12:19] <annevk> smaug____: note that DOMNodeRemoved has much less usage too
# [12:19] * Joins: scheib_ (sid4467@gateway/web/irccloud.com/x-czujdkttezmkyezt)
# [12:20] <smaug____> DOMNodeRemoved happens before the mutation
# [12:20] <annevk> smaug____: btw, I can't get blur to dispatch at all in Gecko for removed nodes
# [12:20] * Joins: c74d3 (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766)
# [12:20] <smaug____> known issue, IIRC
# [12:20] <annevk> smaug____: sure, per "spec" most of them fire at rather problematic times
# [12:20] <smaug____> though
# [12:20] <smaug____> hmm
# [12:20] * Joins: JonathanNeal_ (sid5831@gateway/web/irccloud.com/x-kaqtarfxotqrdwcl)
# [12:20] <smaug____> though, we do have code which should trigger blur
# [12:21] * Joins: tobie_ (sid5692@gateway/web/irccloud.com/x-nleygbtqvjnbdmof)
# [12:21] <smaug____> annevk: so the plan is now to have sync ctors?
# [12:21] <smaug____> for custom elements?
# [12:21] <annevk> smaug____: <p>x<input onblur=alert(1) onfocus=this.parentNode.remove()> is my test
# [12:21] <annevk> smaug____: we don't have a plan yet
# [12:22] * Quits: Sebmaster (sid80609@gateway/web/irccloud.com/x-lpjdqxrvbtqcnmph) (Ping timeout: 240 seconds)
# [12:22] * Quits: cfq (sid18398@gateway/web/irccloud.com/x-onmgrnybbukaqsde) (Ping timeout: 240 seconds)
# [12:22] * Quits: scheib (sid4467@gateway/web/irccloud.com/x-oilxheuklucolzdr) (Ping timeout: 240 seconds)
# [12:22] * Quits: Gege (~gege2@future.deferred.io) (Ping timeout: 240 seconds)
# [12:22] * Quits: JonathanNeal (sid5831@gateway/web/irccloud.com/x-luamtcthvrplygin) (Ping timeout: 240 seconds)
# [12:22] * Quits: bterlson (sid23757@gateway/web/irccloud.com/x-ejulcntzhefebeyr) (Ping timeout: 240 seconds)
# [12:22] * Quits: tobie (sid5692@gateway/web/irccloud.com/x-xxycmthsfackclke) (Ping timeout: 240 seconds)
# [12:22] * Quits: yhirano_ (uid40668@gateway/web/irccloud.com/x-xhrhpguvymibziaw) (Ping timeout: 240 seconds)
# [12:22] * Quits: dmurph (sid42525@gateway/web/irccloud.com/x-ohqxvddrkzfnuxku) (Ping timeout: 240 seconds)
# [12:22] * Quits: twisted` (sid6794@gateway/web/irccloud.com/x-quypcfwjiryydsvu) (Ping timeout: 240 seconds)
# [12:22] * Quits: caitp (~green@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
# [12:22] * Quits: ttepasse (~ttepasse@ip-178-200-61-79.hsi07.unitymediagroup.de) (Ping timeout: 240 seconds)
# [12:22] * Quits: c74d (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766) (Ping timeout: 240 seconds)
# [12:22] * Sebmaster_ is now known as Sebmaster
# [12:22] * scheib_ is now known as scheib
# [12:22] * cfq_ is now known as cfq
# [12:22] * yhirano__ is now known as yhirano_
# [12:22] <smaug____> annevk: could you file a bug. CC enndeakin too
# [12:22] <annevk> smaug____: Google would really like to avoid more synchronous JavaScript during DOM and editing algorithms
# [12:22] * dmurph_ is now known as dmurph
# [12:23] <smaug____> right
# [12:23] * JonathanNeal_ is now known as JonathanNeal
# [12:23] * bterlson_ is now known as bterlson
# [12:23] <annevk> smaug____: so the current plan is exploring whether blur and beforeunload can be made to dispatch using custom element callback timing
# [12:23] <Ms2ger> I don't think we'd mind that either
# [12:23] <smaug____> I was also thinking that maybe we could postpone blur/beforeunload happening during range operations to happen on nanotask
# [12:23] <annevk> (which is better than script runners)
# [12:23] <smaug____> and selection operations would be a nano task or something
# [12:23] <annevk> right, nanotask
# [12:23] <annevk> the thing that doesn't run during compound range operations either
# [12:24] * tobie_ is now known as tobie
# [12:24] * smaug____ doesn't know what is the difference between "custom element callback timing" and script runners
# [12:24] <annevk> smaug____: DOM component?
# [12:24] <annevk> smaug____: afaik script runners run during a single range operation
# [12:25] <annevk> smaug____: nanotask is always at the end of an IDL method or attribute
# [12:25] <smaug____> script runners run when the outermost script blocker goes away from the stack
# [12:25] <annevk> I don't know what that means
# [12:25] <smaug____> there can be nested script blockers
# [12:26] <smaug____> In C++ you have ScriptBlocker object on stack. When it is created, scriptblocking level is increased
# [12:26] <smaug____> when that object is deleted, level is decreased
# [12:26] <smaug____> and when level becomes 0, scriptrunners run
# [12:27] <annevk> I understand that much, but it's unclear whether they can run during https://dom.spec.whatwg.org/#dom-range-extractcontents for instance
# [12:27] <smaug____> those script runners which were posted while the level was != 0
# [12:27] * Joins: Gege (~gege2@future.deferred.io)
# [12:27] <smaug____> currently yes
# [12:27] <annevk> right, which makes them less safe than nanotasks
# [12:27] <smaug____> annevk: but we could effectively put a scriptblocker to selection/editing level code
# [12:27] <annevk> not sure why we keep revisiting this discussion :-)
# [12:28] <smaug____> scriptblockers are nanotasks
# [12:28] <annevk> not if they run during an IDL block
# [12:28] <smaug____> well, in gecko we'd just put scriptblock in the idl block then
# [12:28] <smaug____> scriptblocker
# [12:29] <smaug____> sure, currently ScriptBlockers are used somewhat ad hoc in Gecko
# [12:29] <annevk> once you've made that change we can start calling them nanotasks too
# [12:29] <annevk> until that time the distinction is useful
# [12:29] <smaug____> sure
# [12:30] * Quits: psy_ (~psy@43.224.156.119) (Ping timeout: 244 seconds)
# [12:32] <annevk> smaug____: https://bugzilla.mozilla.org/show_bug.cgi?id=1187848
# [12:33] * Quits: frivoal (~frivoal@por44-h01-176-147-244-60.dsl.sta.abo.bbox.fr) (Remote host closed the connection)
# [12:33] <smaug____> thanks
# [12:33] * smaug____ wonders how this nanotask approach will deal with DOMNodeRemoved
# [12:40] * Joins: twisted` (sid6794@gateway/web/irccloud.com/x-afousrmogiernjyk)
# [12:46] <annevk> smaug____: https://github.com/whatwg/dom/issues/57 has some details from Edge
# [12:47] <annevk> smaug____: seems they do some other things for tree operations compared to other browsers
# [13:01] * Joins: jensnockert (~jensnocke@84.219.248.21)
# [13:06] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 246 seconds)
# [13:06] <philipj> annevk: looks like custom element callbacks are kind of like microtasks but their processed at the boundary between native and script?
# [13:07] <annevk> philipj: only the return boundary
# [13:07] <annevk> philipj: the nickname nanotasks came from that being possible multiple times within a microtask
# [13:07] * Quits: plutoniix (~plutoniix@ppp-124-122-168-180.revip2.asianet.co.th) (Quit: จรลี จรลา)
# [13:08] <philipj> s/their/they're/ unforgivable typo
# [13:11] <philipj> annevk: would there be any benefit to delaying these callback ever so slightly?
# [13:17] <annevk> philipj: "these"?
# [13:18] <philipj> annevk: mutation events I mean
# [13:18] <annevk> philipj: yes, all the code that deals with mutation events changing the world view would go away
# [13:19] <annevk> philipj: and any undiscovered security bugs in those paths would go away too
# [13:22] <philipj> annevk: well, that does sound nice, but mutation events have been annoying for a long time, is any browser willing to attempt the change?
# [13:22] <annevk> philipj: it seems Blink is
# [13:23] <annevk> philipj: see also https://github.com/whatwg/dom/issues/57
# [13:23] <philipj> perhaps I'm overestimating the amount of interop there currently is for these events
# [13:24] <annevk> philipj: it seems Edge has a somewhat different model per that issue
# [13:25] <philipj> Yeah...
# [13:26] <philipj> Some details on that would be nice.
# [13:26] <philipj> Like how would those invariants be enforced, what is it that causes a nested removeChild() call to fail, etc.
# [13:26] <annevk> "https://bugzilla.mozilla.org/show_bug.cgi?id=559561 is pretty ugly
# [13:27] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
# [13:27] * Joins: CvP (~CvP@203.76.123.238)
# [13:27] <philipj> It would be interesting to know how common it is for mutation event listeners to actually mutate the DOM again
# [13:28] <philipj> And if it isn't common at all, if there's a cheap check that could be done to simply disallow that.
# [13:28] * Joins: tripu (~tripu@p2832235-ipngn22701marunouchi.tokyo.ocn.ne.jp)
# [13:28] <philipj> That would make the problems go away I suppose.
# [13:29] <smaug____> Gecko fires non-DOMNodeRemoved mutation events using script runners, so if nano task gets defined, and gecko makes a nano task to be a script blocker, non-DOMNodeRemoved would be fired a bit later in editor/selection case
# [13:30] <annevk> and range case
# [13:31] <smaug____> right
# [13:32] <annevk> so we only run complicated code for DOMNodeRemoved at the moment? and for range operations?
# [13:32] <annevk> hmm
# [13:32] <annevk> I guess that's still less than if custom elements could run code in a bunch of these places
# [13:33] <annevk> And I guess DOMNodeRemoved firing after is problematic because the tree is gone
# [13:33] <annevk> You'd have to do something weird to notify parents
# [13:34] <smaug____> sync custom element ctor case would add yet another new problematic case, cloneNode
# [13:36] <annevk> smaug____: if you already need to code defensively for insertions and removals, is cloning making it much worse?
# [13:36] <smaug____> perhaps not much. But it is yet another case
# [13:37] <smaug____> maybe we'd be better with cloneNode than we were with other cases
# [13:37] * Quits: scrollback1 (scrollback@gateway/web/scrollback.io/x-vshpikilywnfsuov) (Remote host closed the connection)
# [13:37] <smaug____> but would be nice to remove the sync stuff from everywhere
# [13:38] <smaug____> that would simplify code
# [13:38] <smaug____> ...but DOMNodeRemoved...
# [13:38] <annevk> no disagreement there
# [13:38] * smaug____ kicks DOM WG around DOM 2 Events era ;)
# [13:39] * Joins: 7YUAAC9K8 (scrollback@gateway/web/scrollback.io/x-kzxbugpqsgiitily)
# [13:39] <annevk> I'm somewhat surprised they got away with just specifying these events without defining their processing model
# [13:39] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
# [13:40] <smaug____> "processing model" in the web before 2004?
# [13:43] <annevk> hah
# [13:43] * Joins: frivoal (~frivoal@por44-h01-176-147-244-60.dsl.sta.abo.bbox.fr)
# [13:46] * Quits: satazor (~satazor@37.189.179.118) (Remote host closed the connection)
# [13:46] * Joins: satazor (~satazor@37.189.179.118)
# [13:47] * Quits: satazor (~satazor@37.189.179.118) (Remote host closed the connection)
# [13:50] * Joins: CvP (~CvP@203.76.123.238)
# [13:50] * Joins: karlcow (~karl@nerval.la-grange.net)
# [13:59] * Quits: frivoal (~frivoal@por44-h01-176-147-244-60.dsl.sta.abo.bbox.fr) (Remote host closed the connection)
# [14:03] * Quits: ricea (~ricea@2401:fa00:4:1000:d426:7a64:37ad:3cb8) (Quit: Leaving.)
# [14:21] * Joins: encryptd_fractal (~encryptd_@c-24-7-238-5.hsd1.mn.comcast.net)
# [14:30] * Quits: vigilvindex (~quassel@envoycorps.info) (Remote host closed the connection)
# [14:30] * Joins: vigilvindex (~quassel@envoycorps.info)
# [14:34] * Quits: encryptd_fractal (~encryptd_@c-24-7-238-5.hsd1.mn.comcast.net) (Remote host closed the connection)
# [14:37] * Joins: weinig (~weinig@c-50-131-222-145.hsd1.ca.comcast.net)
# [14:42] * Joins: ricea (~ricea@2401:fa00:4:1000:c0b6:41a1:65e6:9003)
# [14:47] * Joins: satazor (~satazor@37.189.179.118)
# [14:51] * Quits: weinig (~weinig@c-50-131-222-145.hsd1.ca.comcast.net) (Quit: weinig)
# [14:51] * Joins: encryptd_fractal (~encryptd_@c-24-7-238-5.hsd1.mn.comcast.net)
# [14:54] * Quits: satazor (~satazor@37.189.179.118) (Ping timeout: 264 seconds)
# [14:59] * Quits: encryptd_fractal (~encryptd_@c-24-7-238-5.hsd1.mn.comcast.net) (Remote host closed the connection)
# [15:02] * Joins: jensnockert (~jensnocke@84.219.248.21)
# [15:07] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 264 seconds)
# [15:11] * Joins: jochen__ (jochen@nat/google/x-iniiasqewaurrbes)
# [15:11] * Joins: smaug_____ (~chatzilla@37-219-245-104.nat.bb.dnainternet.fi)
# [15:11] * Quits: smaug_____ (~chatzilla@37-219-245-104.nat.bb.dnainternet.fi) (Client Quit)
# [15:12] * Joins: smaug_____ (~chatzilla@37-219-245-104.nat.bb.dnainternet.fi)
# [15:12] * Quits: smaug_____ (~chatzilla@37-219-245-104.nat.bb.dnainternet.fi) (Client Quit)
# [15:13] * Joins: smaug_____ (~chatzilla@37-219-245-104.nat.bb.dnainternet.fi)
# [15:14] * Quits: smaug____ (~chatzilla@a91-154-44-165.elisa-laajakaista.fi) (Ping timeout: 255 seconds)
# [15:14] * Quits: smaug_____ (~chatzilla@37-219-245-104.nat.bb.dnainternet.fi) (Client Quit)
# [15:14] * Joins: smaug____ (~chatzilla@37-219-245-104.nat.bb.dnainternet.fi)
# [15:21] <wanderview> annevk: should <applet> be considered a potential client request?
# [15:22] <annevk> wanderview: no
# [15:22] <annevk> wanderview: though <applet> is underspecified
# [15:22] <wanderview> annevk: should it be intercepted? (I guess I need to ask Matt what chrome does)
# [15:22] <annevk> wanderview: it's unclear whether Java does the fetch or the browser and whether all Java fetches are browser-mediated
# [15:23] <annevk> wanderview: there's one open bug against HTML on this, which blocks defining an "applet" context
# [15:24] <wanderview> annevk: if we have no applet context, that implies to me we should not intercept... safe thing to do for now
# [15:28] * Joins: encryptd_fractal (~encryptd_@63-254-58-198.ip.mcleodusa.net)
# [15:28] <annevk> wanderview: we should probably work through the <object> and <embed> cases some more too
# [15:28] * Quits: roc (~chatzilla@121.98.95.75) (Ping timeout: 250 seconds)
# [15:28] <wanderview> annevk: well, for now they are spec'd not to be intercepted
# [15:28] <wanderview> which is at least not a security problem
# [15:32] <wanderview> annevk: I guess its an interesting question for things like amazon.com... they have tons of <object> tags... would they have to rewrite their site to offline it?
# [15:32] <annevk> wanderview: yeah
# [15:32] <annevk> wanderview: the problem with <object> is that its both a client and resource context
# [15:33] <annevk> wanderview: so you don't really know what service worker to use until after you got the response...
# [15:33] <annevk> (if that sounds confusing, it's because it is)
# [15:33] <wanderview> annevk: its ok... I put it in the bucket of "try to understand after we ship v1" for now
# [15:34] <annevk> <applet> doesn't really have that problem, but I'm fine deferring all plugin-like stuff for a bit
# [15:34] <wanderview> yea, makes sense
# [15:34] <annevk> It does sound like Gecko at least manages some of the <applet> requests so I guess I should define a context for it
# [15:34] <annevk> I wonder if anyone can confirm whether that's the case in Chrome too; beverloo maybe?
# [15:35] <annevk> Perhaps mkwst is online? \o/
# [15:35] <wanderview> annevk: I asked Matt Falkenhagen (irc name?)
# [15:35] <annevk> I think matto
# [15:35] <wanderview> he said he would help dig up chrome's behavior for this stuff last week
# [15:35] <annevk> or maybe his last name, not sure
# [15:36] <wanderview> of course... timezones
# [15:36] <annevk> in theory he's had his first work day, but maybe he took a day off, dunno
# [15:36] <mkwst> Hi! Scrolling back, but the question isn't clear to me. What do you want to know about applet?
# [15:37] <annevk> mkwst: basically whether Chrome or Java is in control of fetching
# [15:37] <wanderview> well, I just sent him the email... he's probably just going to bed now :-)
# [15:37] <mkwst> (other than that Sun doesn't seem to be publishing a PPAPI version of Java so maybe we can kill the tag entirely?)
# [15:37] <annevk> aah
# [15:37] <wanderview> mkwst: does chrome do any service worker interception for <applet>
# [15:37] <annevk> (that'd be great)
# [15:38] <annevk> well that's a different question, but I agree it would be good to know the answer to that one too
# [15:38] <mkwst> We certainly trigger the request for the applet itself in Blink, and I suspect we have control over the whole request now that we've killed NPAPI.
# [15:39] <mkwst> But, again, that's fairly theoretical, as I don't think there's any way of running Java in Chrome in Canary. Maybe even stable, I've lost track...
# [15:39] * Joins: scor (~scor@64.231.198.184)
# [15:39] <mkwst> For object and embed it's the same story, except insofar as Flash can open sockets.
# [15:39] * Quits: scor (~scor@64.231.198.184) (Client Quit)
# [15:39] <mkwst> Sockets are outside Fetch, so it can do pretty much whatever it likes with the connection.
# [15:39] <annevk> mkwst: https://java.com/en/download/faq/chrome.xml claims it is still available
# [15:39] <annevk> mkwst: outside of Linux, anyway
# [15:39] * Joins: scor (~scor@drupal.org/user/52142/view)
# [15:40] * Joins: plutoniix (~plutoniix@node-4za.pool-125-25.dynamic.totbb.net)
# [15:40] <annevk> Ooh, that actually tells people to switch the NPAPI flag...
# [15:40] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 246 seconds)
# [15:40] <mkwst> We might have killed the flag by now.
# [15:40] <wanderview> well, object and embed are explicitly not sw intercepted per the current spec
# [15:41] <mkwst> wanderview: Sure. I don't know off the top of my head whether the folks responsible for SW set the bypass flags when making requests. Give me a sec.
# [15:41] <annevk> wanderview: you're saying that Gecko is also in control over the fetch for <applet>, right?
# [15:41] <wanderview> annevk: I haven't looked, but this bug implies it does: https://bugzilla.mozilla.org/show_bug.cgi?id=1187766
# [15:41] <annevk> mkwst: https://github.com/whatwg/fetch/issues/73 is blocking on you
# [15:42] <annevk> mkwst: https://github.com/whatwg/fetch/issues/52 too
# [15:42] <annevk> mkwst: and https://github.com/whatwg/fetch/issues/45
# [15:43] <wanderview> annevk: you mentioned to me somewhere that sicking suggested redesigning context to better handle navigation/worker/client concepts... but you said it was too late... why is it too late?
# [15:43] <annevk> wanderview: I figured since Chrome shipped we might not want to change context
# [15:43] <wanderview> annevk: I don't think they implement .context yet
# [15:43] <wanderview> just a sec
# [15:43] <annevk> wanderview: sicking argued that we basically wanted a single context for everything that creates a browsing context
# [15:44] <annevk> wanderview: and have a distinct flag for "comes from a form" that CSP can use
# [15:44] <wanderview> annevk: they are just implementing it now: https://code.google.com/p/chromium/issues/detail?id=455116
# [15:44] <annevk> hmm okay
# [15:45] <wanderview> annevk: not that I really want to rewrite a bunch of stuff... ehsan might be annoyed :-)
# [15:45] <wanderview> but if its really better... we should consider it
# [15:45] * Joins: karlcow (~karl@nerval.la-grange.net)
# [15:45] <annevk> wanderview: this would only be for all contexts that mean "navigation"
# [15:46] <annevk> I guess I can investigate then, although I hope that doesn't cost too much time :/
# [15:46] <wanderview> ah, that sounds like less of a change
# [15:47] <wanderview> annevk: if you have higher priority stuff... I don't think having the more granular values we do now is bad... just need this extra "is it a navigation" helper
# [15:47] <mkwst> annevk: blocking on me is a seriously bad idea because I am overloaded and behind on everything. But I'll comment on the bugs anyway. :)
# [15:47] <annevk> mkwst: is there a qualified fallback person?
# [15:48] <annevk> mkwst: this is what you get with all those "small" specs :p
# [15:48] <wanderview> mkwst: given that... if you are busy don't worry about the applet... I emailed mattto about it
# [15:48] <mkwst> I think I'm abarth's qualified fallback person.
# [15:48] * Joins: TallTed (~Thud@63.119.36.36)
# [15:48] <annevk> mkwst: we can't have abarth' go MIA too :p
# [15:49] <annevk> maybe I should ask fishd about abarth''
# [15:49] <wanderview> annevk: should the SW spec be doing stuff like step 11 here? or should that be in fetch: http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#on-fetch-request-algorithm
# [15:49] * Quits: boogyman (~mrj@pdpc/supporter/professional/boogyman) (Ping timeout: 265 seconds)
# [15:50] <annevk> wanderview: I think that's fine
# [15:50] <annevk> wanderview: everything about picking a service worker is left up to SW
# [15:51] <wanderview> ok
# [15:51] <wanderview> seems security related which makes me think of those other checks in fetch
# [15:52] <annevk> I think at some point we might need to figure out the layering again, but for now let's leave it like this
# [15:53] <annevk> In general anything Fetch being part of service workers directly is somewhat dirty from a layering perspective
# [15:53] <wanderview> annevk: well, looking at public attributes on Request should be ok
# [15:54] <wanderview> its just annoying to spread security checks between specs where not necessary
# [15:54] * Quits: Lachy (~Lachy@213.166.174.2) (Read error: Connection reset by peer)
# [15:54] * wanderview goes to fetch a baby.
# [15:54] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [15:55] * Joins: Lachy (~Lachy@213.166.174.2)
# [15:55] <annevk> wanderview: oh, I guess it should not look at the public properties
# [15:55] * Joins: scor (~scor@64.231.198.184)
# [15:55] <annevk> wanderview: that seems bad
# [15:55] * Quits: scor (~scor@64.231.198.184) (Changing host)
# [15:55] * Joins: scor (~scor@drupal.org/user/52142/view)
# [15:55] <annevk> wanderview: and I agree with that, but this is about deciding where to handle the fetch, it's not a decision on the response
# [15:56] <annevk> wanderview: where to handle the fetch is not really a security decision per se
# [15:58] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
# [15:58] <annevk> mkwst: ta
# [16:00] <mkwst> annevk: I'm a seriously poor abarth`. At least, I have been this quarter, and August isn't looking any better. Hopefully the next one will be better.
# [16:02] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [16:02] <annevk> mkwst: it's alright, the only thing that's making me nervous is wanderview alluding to us not shipping service workers due to CSP not being ready
# [16:02] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [16:02] * Joins: scor (~scor@64.231.198.184)
# [16:02] * Quits: scor (~scor@64.231.198.184) (Changing host)
# [16:02] * Joins: scor (~scor@drupal.org/user/52142/view)
# [16:02] <mkwst> what, what?
# [16:02] <mkwst> who would be crazy enough to do that? :)
# [16:03] <annevk> I guess we'll have to wait for wanderview to confirm or deny
# [16:04] * Joins: Lachy (~Lachy@213.166.174.2)
# [16:04] <mkwst> Tell me what pieces of CSP are blocking SW, and I will make them go away. Unless it's "This doesn't make sense in terms of Fetch.", in which case, yes, I know, and ugh and I'm working on it. Slowly.
# [16:06] <JakeA> annevk: going to go through https://github.com/whatwg/fetch/issues/79 while I've got a spare moment. Anything else that's particularly blocking?
# [16:07] <annevk> JakeA: no not really
# [16:08] <annevk> mkwst: well one issue we have is that it's unclear what the CSP check on responses will be and indeed whether the service worker can set CSP, etc.
# [16:08] <annevk> mkwst: there's a great many unanswered questions, but perhaps I'm wrong about that blocking us shipping though
# [16:09] <annevk> need to ask wanderview
# [16:09] <wanderview> I'm back
# [16:09] <wanderview> mkwst: annevk: I believe some form of CSP is a blocker for use service workers in firefoxos
# [16:09] <annevk> JakeA: I mean, there's a great number of things I'd like to see resolved, such as range requests
# [16:09] <wanderview> which means its a near time requirement for us
# [16:10] <wanderview> mkwst: annevk: specifically... being able to say if src is constrained to a server... synthetic responses are not allowed... so you can't bypass the no-eval restrictions
# [16:11] * Joins: mven (~textual@32.97.110.56)
# [16:12] <JakeA> annevk: as in, how they appear in a fetch event, how a complete response may be handled, what the cache returns in response to a range, should the browser accept range parts from different sources?
# [16:12] <annevk> JakeA: yeah, those type of questions
# [16:12] <annevk> JakeA: media elements already make them, so I guess to some extent browsers handle them already
# [16:13] <JakeA> yeah, and it feels like having a cache able to produce partial results would be the most compatible and performant way to deal with those
# [16:13] * Joins: satazor (~satazor@37.189.179.118)
# [16:14] <annevk> makes sense
# [16:15] * Quits: satazor (~satazor@37.189.179.118) (Remote host closed the connection)
# [16:16] * Quits: zecho (~zecho@66-247-17-199.northern.mnscu.edu) (Read error: Connection reset by peer)
# [16:16] * Joins: zecho (~zecho@66-247-17-199.northern.mnscu.edu)
# [16:17] <wanderview> I wonder if this overlaps with returning partial responses that are still streaming in for cache.match() of "fetching entry"
# [16:22] <JakeA> wanderview: not sure… we wouldn't want to return an http partial response in response to a non-range request
# [16:22] <JakeA> I think that'd be a failure case
# [16:22] <JakeA> although we might have some magic the other way around
# [16:22] <wanderview> JakeA: I guess the question becomes... do partial responses become a combined complete response when all the pieces are cached?
# [16:23] <JakeA> if the request is a range, and I respond with new Response("hello world"), should SW or Fetch attempt to create an appropriate partial response (I think it should)
# [16:23] * Joins: czerasz2 (~czerasz@efr57.neoplus.adsl.tpnet.pl)
# [16:24] * Joins: czerasz (~czerasz@efr57.neoplus.adsl.tpnet.pl)
# [16:24] <JakeA> wanderview: ohh I see. Yeah, that seems really difficult. We could reject in that case
# [16:24] <wanderview> oh... so Cache stores the whole thing... but might slice it given a range request?
# [16:24] * Joins: JonDavis (~solyce@166.170.42.109)
# [16:24] <JakeA> yeah, that's what I was thinking
# [16:24] <wanderview> that seems reasonable
# [16:25] * JakeA ponders
# [16:25] <wanderview> JakeA: I guess I'm trying to understand what to do in a read-through-cache scenario where a partial request comes... what gets stored in the cache
# [16:25] <JakeA> yeah, I'm thinking the same
# [16:26] <wanderview> aren't you on PTO?
# [16:26] <JakeA> yeah but all my friends are asleep so I'm stuck with you guys
# [16:26] <JakeA> :D
# [16:26] * Joins: satazor (~satazor@37.189.179.118)
# [16:26] <wanderview> ha
# [16:27] <JakeA> so, cache.put(videoRequest.url, fetch(videoRequest.url)).then(r => {)
# [16:27] <JakeA> shit
# [16:27] <JakeA> hit enter too soon
# [16:28] <JakeA> cache.put(videoRequest.url, fetch(videoRequest.url)).then(_ => cache.get(videoRequest))
# [16:28] <wanderview> JakeA: do range requests become less important once we get real streams?
# [16:29] <wanderview> because that snippet of code seems reasonable in a Stream API world
# [16:29] <wanderview> (if requiring some work to implement)
# [16:30] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 244 seconds)
# [16:30] <JakeA> The above would work if the user watched the video sequentially. But if they scrubbed, they'd be waiting for the sequential download to catch up, which isn't great.
# [16:30] <wanderview> right, ok
# [16:30] <JakeA> wanderview: with streams, wouldn't there be a lot of code effort to turn those into range responses?
# [16:31] <JakeA> I guess the question is whether the cache should be that high level
# [16:31] <JakeA> (I'm thinking it should)
# [16:32] <wanderview> maybe we should just look at what http cache offers
# [16:32] * Joins: karlcow (~karl@nerval.la-grange.net)
# [16:32] <wanderview> if it just treats ranges as any other request
# [16:32] <wanderview> or if it does magic
# [16:34] * Quits: caitp- (~green@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Quit: My Mac has gone to sleep. ZZZzzz…)
# [16:35] <annevk> note that for at least some media, we seek to the last set of bytes
# [16:35] <annevk> some containers are broken like that
# [16:35] <annevk> ideally we cleanly handle all those scenarios
# [16:36] <wanderview> section 13.5.4 here suggests that combining is allowed per the spec... who knows if anyone implements it: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html
# [16:36] <annevk> and streams doesn't solve seek and such
# [16:36] <wanderview> http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.5.4
# [16:36] <annevk> I think we're stuck with both
# [16:37] * Joins: caitp (~green@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [16:38] <wanderview> JakeA: I think I might just make the Cache API matching algorithm include range comparisons so they are unique... and then offer a .merge(reqList) to combine them if the client code wants
# [16:38] <wanderview> so read-through-caching works
# [16:38] <wanderview> if they want to optimize and merge they can
# [16:39] <wanderview> and then do your auto-slicing thing on match
# [16:39] <annevk> can't we auto-merge them?
# [16:40] <wanderview> annevk: it seems to me we try to let script control how the Cache works instead of being magical like http cache
# [16:40] <wanderview> so I'd rather give them an API to do it if they want
# [16:40] <annevk> wanderview: hmm, the Cache API is fairly high-level
# [16:40] <annevk> wanderview: e.g. the whole match algorithm
# [16:40] <annevk> for starters
# [16:41] <wanderview> annevk: but we explicitly don't do any *modification* of the cache automatically... its all script controlled
# [16:41] <annevk> I guess, but it does seem fairly silly if range requests/responses require a bunch of make work whereas everything else just works
# [16:42] * Quits: g4 (~g4@unaffiliated/gormer) (Remote host closed the connection)
# [16:42] <wanderview> annevk: the rfc suggests you don't always want to merge... if one part of the range is newer than the rest, etc
# [16:43] <wanderview> anyway... happy to let Jake figure this out while his friends are asleep :-)
# [16:43] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
# [16:43] <annevk> I mean, in that case it says you must discard the older bits
# [16:44] <annevk> If they're not equivalent cache-wise
# [16:44] <wanderview> annevk: and we explicitly don't discard things automatically in Cache API...
# [16:44] <wanderview> the whole point of the API was to let the script decide
# [16:45] * Quits: jochen__ (jochen@nat/google/x-iniiasqewaurrbes) (Remote host closed the connection)
# [16:45] <annevk> fair, but sounds fairly complicated to combine that with ranges
# [16:45] <annevk> and keep the API convenient
# [16:46] <wanderview> they can .match() all the ranges, manually combine into a new Response, and then Cache put it back... the .merge() was a convenience to do that efficiently in the platform
# [16:47] * Joins: ehsan_ (~ehsan@66.207.208.102)
# [16:47] <annevk> you're assuming ranges are non-overlapping
# [16:47] * Joins: eric_carlson (~ericc@17.202.47.189)
# [16:48] <wanderview> am I? it would be a pain, but script could do it with current primitives
# [16:49] <annevk> or maybe you're saying I need to make a side-table to store all the ranges
# [16:49] <annevk> it's not entirely clear to me how to get ranges out of the cache if all I have is a URL
# [16:50] <wanderview> oh... well that would need to be added, yea... I thought we were talking about a world where you could pass range requests to .match()
# [16:51] <wanderview> anyway, if it can be done automatically without losing data then thats cool with me
# [16:54] <JakeA> I'm kinda happy with cache being high level, hopefully idb will become the place to do it if you need lower level
# [16:54] <JakeA> but I need to think about it more
# [16:56] * Quits: JonDavis (~solyce@166.170.42.109) (Ping timeout: 246 seconds)
# [16:56] * Joins: wilsonpage (~wilsonpag@a82-95-85-75.adsl.xs4all.nl)
# [16:56] <wanderview> annevk: why do we even have CORS responses if they can be so easily converted to synthetic responses? should we just have one type?
# [16:57] <annevk> wanderview: https://fetch.spec.whatwg.org/#concept-filtered-response-cors
# [16:57] <wanderview> prevents copying the headers I guess
# [16:58] <annevk> if you ignore some set of data, everything is the same type
# [16:58] <annevk> that's how you end up with == and security bugs
# [16:59] * Quits: czerasz2 (~czerasz@efr57.neoplus.adsl.tpnet.pl) (Ping timeout: 240 seconds)
# [16:59] * Quits: czerasz (~czerasz@efr57.neoplus.adsl.tpnet.pl) (Ping timeout: 252 seconds)
# [16:59] <wanderview> yea, I forgot about the headers... seems we spend all our time worrying about cross-origin body content
# [17:00] <annevk> that's also what leads people to think ReadableStream is all we need
# [17:00] <annevk> might even be the same people
# [17:00] <annevk> :-P
# [17:01] <annevk> (I didn't follow that navigation attack scenario from JakeA btw, seems wrong?)
# [17:03] * Joins: jensnockert (~jensnocke@84.219.248.21)
# [17:04] <JakeA> annevk: Am I right in thinking the attack is exposed when a client request is made to the "infected" url?
# [17:04] <JakeA> that's when the cross-origin code is executing
# [17:05] <JakeA> The bad stuff goes into the cache via a cors request, and comes back out via a client request - that was my understanding, but I haven't seen the attack work (in a while) so I'm not sure
# [17:06] * Joins: JonDavis (~solyce@166.170.41.119)
# [17:07] <annevk> JakeA: oh wait, the Cache API would follow redirects whereas navigation doesn't?
# [17:07] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 240 seconds)
# [17:07] <annevk> JakeA: yeah, I think the Cache API is somewhat broken here, in storing the redirected response but still with the original request URL...
# [17:08] <JakeA> annevk: the cache would end up with an entry where the key was "good site" and the value was "bad site". Then when the navigation happens, the "bad site" entry is pulled out
# [17:09] <JakeA> I mean, they can both be synthetic
# [17:09] <annevk> JakeA: yeah, understood
# [17:09] <wanderview> Cache API should store the final URL property on the Response, no?
# [17:09] <JakeA> yeah
# [17:09] <annevk> JakeA: that seems like a problem with usage of the Cache API
# [17:09] <annevk> JakeA: or design of the Cache API...
# [17:10] <annevk> JakeA: it should be some kind of explicit action to persist a redirect in the cache
# [17:10] <JakeA> I mean, if we're nervous about it, we could consider rejecting if the request/response have different origins. You could still do it with synthetics though
# [17:10] <annevk> A synthetic is explicit
# [17:10] <annevk> Different origins seems ugly
# [17:11] <annevk> And doesn't work for same-origin -> cross-origin -> same-origin
# [17:11] <wanderview> this would be a breaking change, no?
# [17:11] <annevk> Yes
# [17:12] <wanderview> annevk: what about fetch(redirectingURL).then(function(response) { cache.put(sameOriginURL, response) }); ?
# [17:12] <annevk> wanderview: that's fairly explicit too
# [17:12] <wanderview> where the fetch is done external to Cache
# [17:13] <annevk> wanderview: we don't even change contexts in that case
# [17:13] <wanderview> annevk: so you just want to block redirects in cache.add()?
# [17:13] <annevk> wanderview: dunno
# [17:14] * Quits: adactio (~adactio@212.42.170.121) (Quit: adactio)
# [17:15] <annevk> But I don't really think the design of the cache should result in further restrictions in Fetch
# [17:15] <annevk> that seems quite backwards
# [17:15] <annevk> and not actually solving the problem
# [17:15] <annevk> which will popup elsewhere if left unsolved
# [17:15] * Joins: SteveF__ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
# [17:16] <wanderview> annevk: why does this need Cache API? can't the service worker just do a fetch(url, {mode: 'cors'}) and respondWith immediately?
# [17:16] <wanderview> unclear to me why Cache is relevant here
# [17:17] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 265 seconds)
# [17:17] <wanderview> JakeA: why do you need Cache for this? it seems a standalone fetch() could result in "bad stuff"... which is then returned for a client request
# [17:18] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
# [17:18] <JakeA> wanderview: yeah, but it's the cache that may be making it easier for this to happen by accident
# [17:19] <JakeA> right, I'm heading out, just as it was getting interesting. Sorry!
# [17:19] * Joins: jochen__ (jochen@nat/google/x-foiazkyepllseitp)
# [17:19] <wanderview> JakeA: I guess I was asking in reference to annevk's "I don't really think the design of the cache should result in further restrictions in Fetch"
# [17:20] * Quits: SteveF__ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 246 seconds)
# [17:24] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
# [17:26] * Joins: ap (~ap@17.202.44.214)
# [17:29] * Quits: dustinm` (~dustinm@2607:5300:100:200::160d) (K-Lined)
# [17:31] * Joins: IZh (~IZh@192.194.199.35)
# [17:32] * Joins: rektide (~rektide@eldergods.com)
# [17:33] * Joins: dustinm` (~dustinm@105.ip-167-114-152.net)
# [17:33] * Quits: JonDavis (~solyce@166.170.41.119) (Ping timeout: 240 seconds)
# [17:34] * Joins: jernoble|laptop (~jernoble@76.74.153.49)
# [17:34] * Joins: JonDavis (~solyce@mobile-166-171-250-011.mycingular.net)
# [17:37] * Quits: ttepasse_ (~ttepasse@ip-178-200-61-79.hsi07.unitymediagroup.de) (Quit: Textual IRC Client: www.textualapp.com)
# [17:39] * Joins: dbaron (~dbaron@173-228-85-118.dsl.dynamic.fusionbroadband.com)
# [17:42] * Quits: jernoble|laptop (~jernoble@76.74.153.49) (Max SendQ exceeded)
# [17:42] * Joins: psy (~psy@43.224.156.102)
# [17:43] * Joins: jernoble|laptop (~jernoble@76.74.153.49)
# [17:43] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [17:47] * wilsonpage is now known as wilsonpage-away
# [17:47] * Quits: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr) (Excess Flood)
# [17:48] * Quits: jernoble|laptop (~jernoble@76.74.153.49) (Max SendQ exceeded)
# [17:48] * Quits: wilsonpage-away (~wilsonpag@a82-95-85-75.adsl.xs4all.nl) (Quit: My Mac has gone to sleep. ZZZzzz…)
# [17:48] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 255 seconds)
# [17:49] * Joins: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr)
# [17:49] * Joins: jernoble|laptop (~jernoble@76.74.153.49)
# [17:49] * Quits: tripu (~tripu@p2832235-ipngn22701marunouchi.tokyo.ocn.ne.jp) (Quit: Leaving)
# [17:55] * Quits: JonDavis (~solyce@mobile-166-171-250-011.mycingular.net) (Quit: JonDavis)
# [17:55] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [18:00] * Joins: beowulf (~sstewart@host86-179-170-155.range86-179.btcentralplus.com)
# [18:01] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 246 seconds)
# [18:01] * Joins: capella-s3 (~yaaic@cpe-24-59-243-39.twcny.res.rr.com)
# [18:03] * Joins: josemanuel (~josemanue@7.24.11.37.dynamic.jazztel.es)
# [18:07] <JonathanNeal> I’m writing about @font-face and type foundries, but I’m having trouble distinguishing between a distributor like “The League of Movable Type” and “Google Fonts”. Both fulfill the definition, but one doesn’t really produce their own fonts. What do I call something like Google Fonts or TypeKit?
# [18:08] * Joins: benwerd (~benwerd@67.180.159.135)
# [18:09] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [18:17] <wanderview> JakeA: annevk: our http cache behavior for range requests: https://pastebin.mozilla.org/8840726
# [18:19] * Quits: jernoble|laptop (~jernoble@76.74.153.49) (Quit: My Mac has gone to sleep. ZZZzzz…)
# [18:26] * Quits: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net) (Quit: This computer has gone to sleep)
# [18:28] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Quit: Ex-Chat)
# [18:29] * Quits: howdoi_ (uid224@gateway/web/irccloud.com/x-gaivuhlzseyasoro) (Quit: Connection closed for inactivity)
# [18:32] * Joins: JonDavis (~solyce@17.202.50.47)
# [18:33] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [18:34] * Quits: JonDavis (~solyce@17.202.50.47) (Client Quit)
# [18:36] * Quits: espadrine_ (~tyl@213.152.18.159) (Ping timeout: 260 seconds)
# [18:39] * Joins: KevinMarks_ (~yaaic@2607:fb90:5ad:4c48:a6c8:7e2a:4476:58fb)
# [18:40] * Joins: JonDavis (~solyce@17.202.50.47)
# [18:41] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
# [18:41] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [18:41] * Joins: kruppel (~kruppel@192.161.158.18)
# [18:44] <annevk> JonathanNeal: why not just say that some are X, some are Y, some are both?
# [18:44] * Quits: othermaciej (~mjs@104-244-25-60.PUBLIC.monkeybrains.net) (Quit: othermaciej)
# [18:44] * Quits: benwerd (~benwerd@67.180.159.135) (Remote host closed the connection)
# [18:45] <JonathanNeal> annevk: I haven’t found anywhere that really does both.
# [18:45] <annevk> wanderview: whoa, if you do a range request and you get a 200 we refetch?
# [18:45] <annevk> wanderview: I guess that's one case that's not currently considered
# [18:45] <annevk> JonathanNeal: so font foundry vs CDN?
# [18:46] <JonathanNeal> What I’ve learned (or so I think I’ve learned) is that Google Fonts and TypeKit are “typeface directories”.
# [18:46] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [18:46] <annevk> I don't think there's any authority on the terms for those things
# [18:46] <annevk> I guess you could look at Wikipedia
# [18:47] <JonathanNeal> Yeap, Wikipedia and Googling for some kind of blog consensus. TypeKit never refers to themselves as such, since they describe themselves for their service and not their collection.
# [18:47] <annevk> wanderview: also, that seems like an oversimplification, unless we really don't do any validation of the various ranges we have in the cache
# [18:48] <JonathanNeal> annevk: and “directory” is a tricky name, since I think of a typeface directory as the place I put my self hosted fonts for a relative path @font-face rule.
# [18:48] <wanderview> annevk: it probably is a simplification... but I don't think its surprising that implementations do something simpler that might be faster and less complex to implement
# [18:48] * Joins: wilsonpage (~wilsonpag@a82-95-85-75.adsl.xs4all.nl)
# [18:49] * Joins: bnicholson (~bnicholso@corp.mtv2.mozilla.com)
# [18:50] * Quits: josemanuel (~josemanue@7.24.11.37.dynamic.jazztel.es) (Quit: Saliendo)
# [18:50] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [18:52] * Quits: JonDavis (~solyce@17.202.50.47) (Ping timeout: 260 seconds)
# [18:53] * Joins: JonDavis (~solyce@17.202.50.47)
# [18:53] * Quits: KevinMarks_ (~yaaic@2607:fb90:5ad:4c48:a6c8:7e2a:4476:58fb) (Ping timeout: 246 seconds)
# [18:59] * Joins: Lachy (~Lachy@cm-84.215.179.176.getinternet.no)
# [18:59] <annevk> JonathanNeal: I would just go with font CDN and font foundry personally
# [19:00] <annevk> wanderview: or just do something weird :-)
# [19:01] <JonathanNeal> annevk: I’ll consider that, yea. I now appreciate how brew abstracted the whole thing to “taps”.
# [19:01] * Quits: wilsonpage (~wilsonpag@a82-95-85-75.adsl.xs4all.nl) (Quit: My Mac has gone to sleep. ZZZzzz…)
# [19:04] * Joins: jensnockert (~jensnocke@84.219.248.21)
# [19:06] * Parts: IZh (~IZh@192.194.199.35)
# [19:07] * Joins: bholley (~bholley@guest.mtv2.mozilla.com)
# [19:07] * Joins: wilsonpage (~wilsonpag@a82-95-85-75.adsl.xs4all.nl)
# [19:08] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 246 seconds)
# [19:11] * Quits: bholley (~bholley@guest.mtv2.mozilla.com) (Ping timeout: 252 seconds)
# [19:11] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-cteqwvvwrvfxtbfc)
# [19:12] * Joins: jernoble|laptop (~jernoble@17.114.216.82)
# [19:13] * Quits: wilsonpage (~wilsonpag@a82-95-85-75.adsl.xs4all.nl) (Ping timeout: 255 seconds)
# [19:15] * Joins: wilsonpage (~wilsonpag@a82-95-85-75.adsl.xs4all.nl)
# [19:17] <wanderview> annevk: you can always go ask mayhemer to clarify in #necko
# [19:17] * Quits: wilsonpage (~wilsonpag@a82-95-85-75.adsl.xs4all.nl) (Client Quit)
# [19:17] * Joins: othermaciej (~mjs@66.155.106.22)
# [19:18] <annevk> wanderview: I take it you're no longer in #necko :-)
# [19:18] * Joins: weinig (~weinig@17.202.50.223)
# [19:18] <wanderview> annevk: I am... but I don't look at it often... I see you're harassing him now
# [19:19] <annevk> wanderview: do you have useful copy-and-paste for IRC?
# [19:19] <wanderview> annevk: I just copy to pastebin I guess
# [19:19] <annevk> wanderview: would love to have everything from your question down into https://github.com/whatwg/fetch/issues/38 somehow
# [19:20] <wanderview> annevk: I'll copy it
# [19:20] <annevk> wanderview: but whenever I copy-and-paste the formatting around the nickname goes all bonkers
# [19:20] <annevk> ta
# [19:20] <wanderview> I think irccloud works ok for this
# [19:20] <annevk> LimeChat--
# [19:21] <wanderview> done
# [19:21] <wanderview> annevk: mozilla instance of irccloud works pretty well
# [19:22] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [19:22] <annevk> Yeah, I guess I should switch, mostly been putting it off due to inertia
# [19:22] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Client Quit)
# [19:22] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [19:23] <wanderview> annevk: hmm... it did lose the names on the log when I pasted it
# [19:24] <wanderview> I'll fix it
# [19:24] * Joins: benwerd (~benwerd@67.180.159.135)
# [19:27] <wanderview> annevk: I guess irccloud messed up too... put names in brackets like <bkelly>... which markdown just treats as html and hides
# [19:27] <annevk> wanderview: use ``` and ``` around it?
# [19:28] <annevk> wanderview: GitHub might even support ```irc for IRC highlighting...
# [19:28] <wanderview> annevk: I already modified it to show in markdown
# [19:29] <annevk> ait
# [19:29] * Joins: ambv (~ambv@199.201.64.129)
# [19:29] <wanderview> annevk: what does "ait" mean?
# [19:30] <annevk> alright
# [19:30] <wanderview> ait
# [19:30] <annevk> k
# [19:32] * Joins: JonathanDavis (~solyce@17.114.218.249)
# [19:33] * Joins: jernoble (~jernoble@17.202.46.221)
# [19:34] * Quits: othermaciej (~mjs@66.155.106.22) (Quit: othermaciej)
# [19:34] * Joins: tantek (~tantek@guest-nat.p2p.sfo1.mozilla.com)
# [19:34] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [19:34] * Quits: JonDavis (~solyce@17.202.50.47) (Ping timeout: 265 seconds)
# [19:34] * JonathanDavis is now known as JonDavis
# [19:35] * Quits: Lachy (~Lachy@cm-84.215.179.176.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [19:37] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [19:37] <wanderview> annevk: if there is a defined RequestContext enum value in fetch... does that mean it should be intercepted? or just that you think it might be reasonable to intercept if someone wants to spec it?
# [19:38] * Joins: weinig_ (~weinig@17.114.217.171)
# [19:39] * Quits: jernoble (~jernoble@17.202.46.221) (Quit: Textual IRC Client: www.textualapp.com)
# [19:39] * Quits: weinig (~weinig@17.202.50.223) (Ping timeout: 260 seconds)
# [19:39] * weinig_ is now known as weinig
# [19:39] <annevk> wanderview: in principle I think everything should be intercepted
# [19:41] <wanderview> annevk: I feel I can usefully take this statement out of context... thanks
# [19:42] * Krinkle_ is now known as Krinkle
# [19:45] <annevk> hah
# [19:52] * hallvors wants to joke about annevk and the NSA
# [19:53] * Joins: jwalden (~waldo@2620:101:80fc:224:7e7a:91ff:fe25:a5a3)
# [19:54] <hallvors> annevk: joking aside, on to spec editing style questions
# [19:54] <annevk> evening hallvors
# [19:55] <hallvors> I like having a prose description of what we're up to
# [19:55] <annevk> hallvors: so one problem with the before* not being integrated is that it's not very clear when they fire in relation to the other events
# [19:55] <annevk> hallvors: and whether they fire from different tasks or not
# [19:55] <hallvors> aha
# [19:55] <annevk> hallvors: and what happens if you launch a copy operation from one of them
# [19:55] <annevk> hallvors: etc.
# [19:55] * Joins: jsbell (jsbell@nat/google/x-yrskrthnlpoguyjz)
# [19:56] <hallvors> there is a "processing model" section for them, but *when* they fire is not spec'ed
# [19:56] <hallvors> https://w3c.github.io/clipboard-apis/#processing-model-for-before-events
# [19:56] <annevk> hallvors: if you don't have a very clear set of steps, it's super easy to poke holes
# [19:57] <annevk> hallvors: so those fiddle with a command state in the end, which requires more than just firing an event
# [19:57] <annevk> hallvors: they require execution of some command
# [19:57] <hallvors> exactly when to fire them is left up to the implementation.. they aren't really about commands, they are about UI
# [19:57] <annevk> hallvors: currently you'd get a nullpointer exception
# [19:58] <annevk> hallvors: well presumably they fire in response to some action by the user, from a task
# [19:58] <hallvors> I may need a better word than "command"..
# [19:59] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [19:59] <hallvors> it's up to the UA when to fire them, but typically it would happen for example when the user opens the "Edit" menu
# [20:00] <annevk> ah right, they're unrelated to firing of the non-before events
# [20:00] * Quits: weinig (~weinig@17.114.217.171) (Quit: weinig)
# [20:00] * Quits: JonDavis (~solyce@17.114.218.249) (Quit: JonDavis)
# [20:00] <hallvors> so the UA is about to show the user a menu containing "copy"/"cut"/"paste" commands, and wants to enable or disable them
# [20:00] <hallvors> exactly. They are sort of completely unrelated to those other clipboard events..
# [20:00] * Joins: weinig (~weinig@17.114.217.171)
# [20:00] <annevk> so what you actually want to define then is a set of steps for displaying "edit UI"
# [20:01] <annevk> And then you have an algorithm whenever you "display edit UI"
# [20:01] <annevk> To figure out how you display it
# [20:01] * Quits: weinig (~weinig@17.114.217.171) (Client Quit)
# [20:01] <annevk> It happens to run some script from a queued task to figure that out
# [20:01] <annevk> Do you get distinct tasks for each event? Or do they share a task?
# [20:01] <annevk> That's the kind of thing that should be obvious from that algorithm
# [20:02] * Joins: ap_ (~ap@17.114.218.89)
# [20:02] <hallvors> right
# [20:02] * hallvors will report a github issue on the spec
# [20:02] * Joins: JonDavis (~solyce@17.114.218.249)
# [20:02] <hallvors> spent way too much time on this today already due to git doing things I didn't understand..
# [20:02] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 240 seconds)
# [20:03] * Joins: weinig (~weinig@17.114.217.171)
# [20:03] <annevk> ah sorry :-(
# [20:03] <annevk> tooling issues are the worst
# [20:03] * Joins: jernoble (~jernoble@17.202.46.221)
# [20:03] <hallvors> well, it's not your fault :)
# [20:03] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 244 seconds)
# [20:03] <hallvors> I assume :)
# [20:03] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [20:03] <annevk> I guess sympathize is a better word
# [20:04] * Joins: othermaciej (~mjs@17.114.218.184)
# [20:04] <hallvors> thanks! appreciated. I got into some weird state where a submodule was there but wasn't there. somehow.
# [20:04] <hallvors> #-]
# [20:04] * Quits: weinig (~weinig@17.114.217.171) (Client Quit)
# [20:05] <annevk> I usually lazy-IRC for all git issues I encounter
# [20:05] * Quits: ap (~ap@17.202.44.214) (Ping timeout: 260 seconds)
# [20:05] <annevk> There's a surprising number of people on #whatwg who know what's what
# [20:05] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [20:05] <hallvors> well, MikeSmith helped me out in irc.w3's#testing
# [20:06] * Joins: karlcow (~karl@nerval.la-grange.net)
# [20:08] * Quits: JonDavis (~solyce@17.114.218.249) (Quit: JonDavis)
# [20:08] * Joins: rniwa (~rniwa@17.202.50.208)
# [20:09] <annevk> back later, time for a break
# [20:12] * Joins: JonDavis (~solyce@17.114.218.249)
# [20:22] * Quits: psy (~psy@43.224.156.102) (Disconnected by services)
# [20:22] * Joins: psy_ (~psy@43.224.156.102)
# [20:23] * Quits: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr) (Excess Flood)
# [20:24] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [20:24] * Quits: JonDavis (~solyce@17.114.218.249) (Quit: JonDavis)
# [20:27] * Joins: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr)
# [20:29] * Quits: tantek (~tantek@guest-nat.p2p.sfo1.mozilla.com) (Quit: tantek)
# [20:32] * Quits: dbaron (~dbaron@173-228-85-118.dsl.dynamic.fusionbroadband.com) (Ping timeout: 260 seconds)
# [20:33] * Quits: rniwa (~rniwa@17.202.50.208) (Ping timeout: 256 seconds)
# [20:39] * Quits: CvP (~CvP@203.76.123.238) (Disconnected by services)
# [20:39] * Joins: xCG (~CvP@203.76.123.238)
# [20:39] * xCG is now known as CvP
# [20:40] * Joins: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com)
# [20:43] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 244 seconds)
# [20:46] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
# [20:46] * Joins: bin_005 (~ctlM@80.83.238.11)
# [20:52] * Quits: kruppel (~kruppel@192.161.158.18) (Quit: My Mac has gone to sleep. ZZZzzz…)
# [20:52] * Joins: kruppel (~kruppel@192.161.158.18)
# [20:55] * Quits: othermaciej (~mjs@17.114.218.184) (Quit: othermaciej)
# [20:55] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [20:56] * Joins: ccardona-work (~ccardona-@209.213.209.190)
# [20:56] <ccardona-work> o/ whatwg
# [20:58] <wanderview> writing this blog post is triggering all my worst procrastination tendencies from school
# [20:59] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [20:59] * Joins: JonDavis (~solyce@17.114.183.204)
# [20:59] * Joins: othermaciej (~mjs@17.114.218.184)
# [21:00] * Quits: ccardona-work (~ccardona-@209.213.209.190) (Quit: ccardona-work)
# [21:00] * Quits: JonDavis (~solyce@17.114.183.204) (Client Quit)
# [21:01] * Joins: ccardona-work (~ccardona-@209.213.209.190)
# [21:02] * Joins: JonDavis (~solyce@17.114.183.204)
# [21:03] * Quits: othermaciej (~mjs@17.114.218.184) (Client Quit)
# [21:05] * Joins: jensnockert (~jensnocke@84.219.248.21)
# [21:05] * Quits: jwalden (~waldo@2620:101:80fc:224:7e7a:91ff:fe25:a5a3) (Quit: need power, back soonish)
# [21:06] * Joins: othermaciej (~mjs@17.114.218.184)
# [21:09] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
# [21:10] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 255 seconds)
# [21:10] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [21:10] <JonathanNeal> Is there a name for the css pattern seen as url(), local(), and format() ?
# [21:11] <Ms2ger> Function?
# [21:14] * Quits: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com) (Quit: tantek)
# [21:16] * Joins: Lachy (~Lachy@cm-84.215.179.176.getinternet.no)
# [21:18] * Quits: dgrogan (dgrogan@nat/google/x-hxnatnjnusewfhuv) (Ping timeout: 244 seconds)
# [21:21] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Quit: ChatZilla 0.9.91.1 [Firefox 39.0/20150630154324])
# [21:24] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [21:27] * Quits: jsbell (jsbell@nat/google/x-yrskrthnlpoguyjz) (Ping timeout: 244 seconds)
# [21:27] * Joins: dbaron (~dbaron@2620:101:80fb:224:65b7:8fce:449d:9ac0)
# [21:28] * Krinkle is now known as Krinkle_
# [21:31] * Joins: jwalden (~waldo@2620:101:80fc:224:7e7a:91ff:fe25:a5a3)
# [21:34] * Quits: jwalden (~waldo@2620:101:80fc:224:7e7a:91ff:fe25:a5a3) (Client Quit)
# [21:37] <TabAtkins> annevk: Something like "In parallel with the rest of the algorithm, run the following steps:" would work. As it's written, the "in parallel" part is implied to apply over the "following steps" not over the rest of the algorithm as it should be.
# [21:37] * Joins: espadrine_ (~tyl@dan75-7-88-166-187-54.fbx.proxad.net)
# [21:37] <TabAtkins> JonathanNeal: Yes, function. Or functional notation, either works.
# [21:38] <JonathanNeal> Thank you, Ms2ger, TabAtkins. :)
# [21:50] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [21:50] * Quits: espadrine_ (~tyl@dan75-7-88-166-187-54.fbx.proxad.net) (Ping timeout: 260 seconds)
# [21:53] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [21:54] * Joins: jwalden (~waldo@2620:101:80fc:224:7e7a:91ff:fe25:a5a3)
# [21:55] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [21:58] * Joins: tantek (~tantek@guest-nat.p2p.sfo1.mozilla.com)
# [22:01] * Quits: JonDavis (~solyce@17.114.183.204) (Quit: JonDavis)
# [22:05] * Quits: ccardona-work (~ccardona-@209.213.209.190) (Quit: ccardona-work)
# [22:06] * Joins: frivoal (~frivoal@por44-h01-176-147-244-60.dsl.sta.abo.bbox.fr)
# [22:08] * Quits: othermaciej (~mjs@17.114.218.184) (Quit: othermaciej)
# [22:14] * Quits: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek) (Quit: Leaving.)
# [22:30] * Joins: ttepasse (~ttepasse@ip-178-200-61-79.hsi07.unitymediagroup.de)
# [22:30] * Quits: frivoal (~frivoal@por44-h01-176-147-244-60.dsl.sta.abo.bbox.fr) (Remote host closed the connection)
# [22:31] * Joins: othermaciej (~mjs@17.114.218.184)
# [22:33] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Read error: Connection reset by peer)
# [22:33] * Quits: eric_carlson (~ericc@17.202.47.189) (Quit: eric_carlson)
# [22:34] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [22:34] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [22:35] * Joins: eric_carlson (~ericc@17.202.47.189)
# [22:35] * Joins: ccardona-work (~ccardona-@209.213.209.190)
# [22:36] * Quits: eric_carlson (~ericc@17.202.47.189) (Client Quit)
# [22:41] * Krinkle_ is now known as Krinkle
# [22:43] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [22:44] * Quits: bin_005 (~ctlM@80.83.238.11) (Ping timeout: 255 seconds)
# [22:45] * Joins: czerasz2 (~czerasz@x5ce1583b.dyn.telefonica.de)
# [22:46] * Joins: czerasz (~czerasz@x5ce1583b.dyn.telefonica.de)
# [22:52] * Joins: boogyman (~mrj@d-65-175-179-47.cpe.metrocast.net)
# [22:52] * Quits: boogyman (~mrj@d-65-175-179-47.cpe.metrocast.net) (Changing host)
# [22:52] * Joins: boogyman (~mrj@pdpc/supporter/professional/boogyman)
# [22:53] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Read error: Connection reset by peer)
# [22:53] * Quits: boogyman (~mrj@pdpc/supporter/professional/boogyman) (Client Quit)
# [22:54] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [22:54] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [22:54] * Joins: bin_005 (~ctlM@80.83.238.24)
# [22:59] * Quits: robogoat (~robogoat@c-24-126-240-124.hsd1.ga.comcast.net) (Ping timeout: 264 seconds)
# [23:00] * Quits: TallTed (~Thud@63.119.36.36)
# [23:01] * Joins: robogoat (~robogoat@c-24-126-240-124.hsd1.ga.comcast.net)
# [23:02] * Quits: bin_005 (~ctlM@80.83.238.24) (Ping timeout: 244 seconds)
# [23:04] * Joins: eric_carlson (~ericc@17.202.47.189)
# [23:05] * Quits: lerc (~quassel@121-74-249-71.telstraclear.net) (Read error: Connection reset by peer)
# [23:06] * Joins: jensnockert (~jensnocke@84.219.248.21)
# [23:11] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 255 seconds)
# [23:11] * Quits: qard (~sbelanger@209.139.228.33) (Read error: Connection reset by peer)
# [23:12] * Quits: jyasskin_w (jyasskin@nat/google/x-gklednikmbfaddyd) (Ping timeout: 244 seconds)
# [23:13] * Quits: satazor (~satazor@37.189.179.118) (Remote host closed the connection)
# [23:14] * Joins: qard (~sbelanger@209.139.228.33)
# [23:26] * Joins: jyasskin_w (jyasskin@nat/google/x-uaqjihrngynhqbfg)
# [23:26] * Quits: Tenhi (~tenhi@178.18.241.180) (Ping timeout: 264 seconds)
# [23:31] * Joins: Tenhi (~tenhi@178.18.241.180)
# [23:32] <annevk> TabAtkins: shrug, file bugs?
# [23:38] * Quits: ccardona-work (~ccardona-@209.213.209.190) (Quit: ccardona-work)
# [23:46] * Joins: roc (~chatzilla@121.98.95.75)
# [23:53] * Quits: Maurice` (copyman@unaffiliated/maurice)
# [23:55] * Quits: ttepasse (~ttepasse@ip-178-200-61-79.hsi07.unitymediagroup.de) (Quit: Textual IRC Client: www.textualapp.com)
# [23:56] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
# [23:57] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [23:58] * Quits: eric_carlson (~ericc@17.202.47.189) (Ping timeout: 240 seconds)
# Session Close: Tue Jul 28 00:00:00 2015

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn