Options:
Previous day, Next day
- # Session Start: Tue Jan 20 00:00:00 2015
- # Session Ident: #whatwg
- # [00:00] * Quits: weinig (~weinig@17.245.28.132) (Quit: weinig)
- # [00:01] * Quits: Maurice` (copyman@unaffiliated/maurice)
- # [00:02] * Quits: ap (~ap@17.114.217.173)
- # [00:06] * Quits: darobin (~darobin@2a01:e34:ed05:d180:102e:6a4b:c435:395d) (Remote host closed the connection)
- # [00:06] * Quits: danbri (~Adium@host86-191-96-32.range86-191.btcentralplus.com) (Quit: Leaving.)
- # [00:08] * Joins: ehsan (~ehsan@24-212-206-173.cable.teksavvy.com)
- # [00:12] * Joins: watilde (~watilde@i114-180-108-27.s04.a013.ap.plala.or.jp)
- # [00:13] * Quits: ehsan (~ehsan@24-212-206-173.cable.teksavvy.com) (Ping timeout: 272 seconds)
- # [00:13] * Quits: watilde (~watilde@i114-180-108-27.s04.a013.ap.plala.or.jp) (Client Quit)
- # [00:13] * Quits: rniwa (~rniwa@67.164.23.121) (Quit: rniwa)
- # [00:15] * Joins: ap (~ap@17.114.217.173)
- # [00:19] * Quits: eric_carlson (~ericc@17.114.217.57) (Quit: eric_carlson)
- # [00:19] * Joins: Caspy7 (~chatzilla@99.185.26.234)
- # [00:29] * Quits: booly-yam-6137 (~cinch@bzq-79-178-15-163.red.bezeqint.net) (Ping timeout: 244 seconds)
- # [00:29] * Quits: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
- # [00:32] * Joins: booly-yam-6137 (~cinch@bzq-79-178-15-163.red.bezeqint.net)
- # [00:33] * Joins: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [00:37] * Joins: danbri (~Adium@host86-191-96-32.range86-191.btcentralplus.com)
- # [00:42] * Quits: danbri (~Adium@host86-191-96-32.range86-191.btcentralplus.com) (Ping timeout: 264 seconds)
- # [00:43] * Joins: weinig (~weinig@17.245.28.132)
- # [00:45] * Joins: rniwa (~rniwa@67.164.23.121)
- # [00:46] * Quits: mven (~textual@32.97.110.56) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
- # [00:51] * Joins: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
- # [00:57] * Quits: encryptd_fractl (~encryptd_@12.148.211.210) (Remote host closed the connection)
- # [01:00] * Quits: Caspy7 (~chatzilla@99.185.26.234) (Ping timeout: 252 seconds)
- # [01:00] * heycam is now known as heycam|away
- # [01:00] * heycam|away is now known as heycam
- # [01:06] * Joins: mven (~textual@72.183.104.138)
- # [01:07] * Joins: danbri (~Adium@host86-191-96-32.range86-191.btcentralplus.com)
- # [01:10] * Quits: mven (~textual@72.183.104.138) (Client Quit)
- # [01:13] * Quits: danbri (~Adium@host86-191-96-32.range86-191.btcentralplus.com) (Ping timeout: 246 seconds)
- # [01:16] * Quits: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
- # [01:28] * Quits: thinkxl (~thinkxl@2601:e:2980:cb00:8aa:f609:83b:a6e4) (Ping timeout: 245 seconds)
- # [01:28] * Joins: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp)
- # [01:32] * Quits: weinig (~weinig@17.245.28.132) (Quit: weinig)
- # [01:32] * Quits: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp) (Ping timeout: 244 seconds)
- # [01:35] * Joins: eric_carlson (~ericc@24.6.239.9)
- # [01:35] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 256 seconds)
- # [01:37] * heycam is now known as heycam|away
- # [01:44] * Joins: plutoniix (~plutoniix@119.63.87.222)
- # [01:46] * Quits: ^esc (~esc-ape@77.119.130.200.wireless.dyn.drei.com) (Remote host closed the connection)
- # [01:47] * Joins: ^esc (~esc-ape@77.119.130.200.wireless.dyn.drei.com)
- # [01:50] * Joins: weinig (~weinig@17.244.161.119)
- # [01:51] * Joins: jarek (~jarek@unaffiliated/jarek)
- # [01:52] * Joins: satazor_ (~satazor@37.189.3.135)
- # [01:54] * Quits: satazor (~satazor@89.114.99.80) (Ping timeout: 240 seconds)
- # [01:59] * Quits: weinig (~weinig@17.244.161.119) (Quit: weinig)
- # [02:01] * heycam|away is now known as heycam
- # [02:05] * Quits: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
- # [02:08] * Quits: seventh (seventh@31.6.30.17) (Quit: ...)
- # [02:10] * Joins: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [02:13] * Quits: satazor_ (~satazor@37.189.3.135) (Ping timeout: 246 seconds)
- # [02:17] * Joins: tommyliu (~tommyliu@116.247.108.182)
- # [02:19] * Quits: tommyliu (~tommyliu@116.247.108.182) (Remote host closed the connection)
- # [02:19] * Joins: tommyliu (~tommyliu@116.247.108.182)
- # [02:20] * Quits: tommyliu (~tommyliu@116.247.108.182) (Read error: Connection reset by peer)
- # [02:20] * Joins: weinig (~weinig@17.244.161.119)
- # [02:20] * Joins: jdaggett (~jdaggett@103.5.142.54)
- # [02:21] * Joins: tommyliu (~tommyliu@li587-82.members.linode.com)
- # [02:24] * Joins: tommyliu_ (~tommyliu@li446-72.members.linode.com)
- # [02:28] * Quits: tommyliu (~tommyliu@li587-82.members.linode.com) (Ping timeout: 244 seconds)
- # [02:29] * Quits: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 246 seconds)
- # [02:31] * Quits: ap (~ap@17.114.217.173)
- # [02:32] * Joins: KevinMarks (~yaaic@2607:fb90:2853:5f81:8bea:58ba:f0d3:f5cd)
- # [02:36] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: jarek)
- # [02:39] * Quits: weinig (~weinig@17.244.161.119) (Quit: weinig)
- # [02:40] * Joins: weinig (~weinig@17.244.161.119)
- # [02:44] * Joins: Caspy7 (~chatzilla@99.185.26.234)
- # [02:57] * Joins: ehsan (~ehsan@24-212-206-173.cable.teksavvy.com)
- # [03:02] * Quits: ehsan (~ehsan@24-212-206-173.cable.teksavvy.com) (Ping timeout: 252 seconds)
- # [03:07] * Quits: eric_carlson (~ericc@24.6.239.9) (Quit: eric_carlson)
- # [03:08] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [03:11] * Joins: encryptd_fractl (~encryptd_@24-177-122-160.dhcp.mdsn.wi.charter.com)
- # [03:12] * Quits: KevinMarks (~yaaic@2607:fb90:2853:5f81:8bea:58ba:f0d3:f5cd) (Ping timeout: 245 seconds)
- # [03:14] * Joins: tommyliu (~tommyliu@116.247.108.182)
- # [03:16] * Quits: tommyliu_ (~tommyliu@li446-72.members.linode.com) (Ping timeout: 240 seconds)
- # [03:17] * Joins: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp)
- # [03:18] * Quits: jdaggett (~jdaggett@103.5.142.54) (Quit: jdaggett)
- # [03:21] * Quits: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp) (Ping timeout: 245 seconds)
- # [03:22] * Joins: eric_carlson (~ericc@24.6.239.9)
- # [03:22] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [03:23] * Joins: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com)
- # [03:27] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Client Quit)
- # [03:29] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [03:30] * Joins: tripu (~tripu@2001:200:0:8805:8dae:8a45:233e:41c7)
- # [03:31] * Quits: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com) (Ping timeout: 252 seconds)
- # [03:33] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
- # [03:33] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
- # [03:33] * Joins: scor (~scor@drupal.org/user/52142/view)
- # [03:34] * heycam is now known as heycam|away
- # [03:35] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [03:37] * Quits: eric_carlson (~ericc@24.6.239.9) (Quit: eric_carlson)
- # [03:42] * Joins: jdaggett (~jdaggett@pw126255069075.9.panda-world.ne.jp)
- # [03:55] * Quits: tommyliu (~tommyliu@116.247.108.182) (Remote host closed the connection)
- # [03:56] * Quits: ^esc (~esc-ape@77.119.130.200.wireless.dyn.drei.com) (Ping timeout: 264 seconds)
- # [03:57] * heycam|away is now known as heycam
- # [03:57] * Joins: kapil__ (uid36151@gateway/web/irccloud.com/x-fwgsuuudlmkilnik)
- # [04:05] * Joins: tommyliu_ (~tommyliu@116.247.108.182)
- # [04:10] * Quits: tommyliu_ (~tommyliu@116.247.108.182) (Ping timeout: 245 seconds)
- # [04:10] * Quits: plutoniix (~plutoniix@119.63.87.222) (Ping timeout: 245 seconds)
- # [04:17] * Joins: plutoniix (~plutoniix@119.63.87.222)
- # [04:18] * Joins: tommyliu (~tommyliu@116.247.108.182)
- # [04:19] * Quits: tommyliu (~tommyliu@116.247.108.182) (Read error: Connection reset by peer)
- # [04:20] * Joins: tommyliu (~tommyliu@li446-72.members.linode.com)
- # [04:22] * Joins: jacobolu_ (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
- # [04:24] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 264 seconds)
- # [04:24] * Quits: jdaggett (~jdaggett@pw126255069075.9.panda-world.ne.jp) (Read error: Connection reset by peer)
- # [04:47] * Joins: ehsan (~ehsan@24-212-206-173.cable.teksavvy.com)
- # [04:51] * Quits: ehsan (~ehsan@24-212-206-173.cable.teksavvy.com) (Ping timeout: 245 seconds)
- # [04:53] * Quits: tommyliu (~tommyliu@li446-72.members.linode.com) (Remote host closed the connection)
- # [05:03] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [05:05] * Joins: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp)
- # [05:08] * Quits: weinig (~weinig@17.244.161.119) (Quit: weinig)
- # [05:10] * Quits: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp) (Ping timeout: 245 seconds)
- # [05:14] * Joins: mven (~textual@72.183.104.138)
- # [05:17] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [05:18] * Quits: Caspy7 (~chatzilla@99.185.26.234) (Read error: Connection reset by peer)
- # [05:21] * Quits: tripu (~tripu@2001:200:0:8805:8dae:8a45:233e:41c7) (Ping timeout: 265 seconds)
- # [05:34] * Joins: lilmonkey` (~colin@pdpc/supporter/professional/riven)
- # [05:38] * Quits: lilmonkey (~colin@pdpc/supporter/professional/riven) (Ping timeout: 265 seconds)
- # [05:42] * Quits: kochi (~kochi@2401:fa00:4:1000:d4d4:4321:e79f:3032) (Remote host closed the connection)
- # [05:45] * Joins: tripu (~tripu@2001:200:0:8805:8dae:8a45:233e:41c7)
- # [05:46] * heycam is now known as heycam|away
- # [05:48] * Quits: tav (~tav`@host31-52-138-176.range31-52.btcentralplus.com) (Quit: Hakuna Matata!)
- # [05:49] * Joins: tav (~tav`@host31-52-138-176.range31-52.btcentralplus.com)
- # [05:54] * Joins: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon)
- # [05:58] * Joins: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
- # [06:05] * Quits: mven (~textual@72.183.104.138) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
- # [06:17] * Quits: igoroliveira (uid20755@gateway/web/irccloud.com/x-vbhbeesioytphfbh) (Quit: Connection closed for inactivity)
- # [06:19] * Joins: yoichio (yoichio@nat/google/x-yqkrzkgknhumfhvv)
- # [06:19] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 245 seconds)
- # [06:21] * Quits: rniwa (~rniwa@67.164.23.121) (Quit: rniwa)
- # [06:27] * slightlyoff_ is now known as slightlyoff
- # [06:41] * Quits: hallvors (uid23371@gateway/web/irccloud.com/x-uppfamwntdjtsryo) (Quit: Connection closed for inactivity)
- # [06:47] * Quits: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
- # [06:54] * Joins: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp)
- # [06:59] * Quits: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp) (Ping timeout: 245 seconds)
- # [07:06] * Joins: jsx (uid48919@fsf/intern/jsx)
- # [07:12] * Joins: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com)
- # [07:15] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [07:20] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 245 seconds)
- # [07:28] * Joins: tommyliu (~tommyliu@180.171.97.117)
- # [07:32] * Quits: tommyliu (~tommyliu@180.171.97.117) (Read error: Connection reset by peer)
- # [07:32] * Joins: tommyliu (~tommyliu@116.251.214.16)
- # [07:34] * Joins: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si)
- # [07:36] * Joins: ehsan_ (~ehsan@24-212-206-173.cable.teksavvy.com)
- # [07:36] * Quits: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net) (Ping timeout: 264 seconds)
- # [07:38] * Quits: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si) (Client Quit)
- # [07:39] * Joins: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek)
- # [07:40] * Joins: iandevlin (~iandevlin@dslb-088-078-251-070.088.078.pools.vodafone-ip.de)
- # [07:41] * Quits: ehsan_ (~ehsan@24-212-206-173.cable.teksavvy.com) (Ping timeout: 256 seconds)
- # [07:49] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [07:50] * Joins: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net)
- # [07:54] * Joins: jdaggett (~jdaggett@ad056175.dynamic.ppp.asahi-net.or.jp)
- # [07:55] * Joins: kochi (~kochi@2401:fa00:4:1000:55b9:66c8:5929:c966)
- # [08:06] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 264 seconds)
- # [08:07] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
- # [08:10] * Joins: tommyliu_ (~tommyliu@23.228.209.28)
- # [08:11] * Quits: plutoniix (~plutoniix@119.63.87.222) (Ping timeout: 256 seconds)
- # [08:11] * Quits: tommyliu (~tommyliu@116.251.214.16) (Read error: Connection reset by peer)
- # [08:14] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [08:21] * Joins: tommyliu (~tommyliu@180.171.97.117)
- # [08:21] * Quits: booly-yam-6137 (~cinch@bzq-79-178-15-163.red.bezeqint.net) (Ping timeout: 256 seconds)
- # [08:22] * Quits: tommyliu (~tommyliu@180.171.97.117) (Read error: Connection reset by peer)
- # [08:22] * Quits: tommyliu_ (~tommyliu@23.228.209.28) (Ping timeout: 256 seconds)
- # [08:22] * Joins: tommyliu (~tommyliu@v17.blockcn.net)
- # [08:27] * Joins: plutoniix (~plutoniix@119.63.87.222)
- # [08:31] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [08:32] * Joins: tommyliu_ (~tommyliu@180.171.97.117)
- # [08:32] * Quits: tommyliu_ (~tommyliu@180.171.97.117) (Read error: Connection reset by peer)
- # [08:33] * Quits: tommyliu (~tommyliu@v17.blockcn.net) (Ping timeout: 252 seconds)
- # [08:36] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [08:36] * Quits: jdaggett (~jdaggett@ad056175.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
- # [08:37] * Joins: ^esc (~esc-ape@178.115.129.182.wireless.dyn.drei.com)
- # [08:41] * Joins: tommyliu (~tommyliu@180.171.97.117)
- # [08:43] * Quits: tommyliu (~tommyliu@180.171.97.117) (Read error: Connection reset by peer)
- # [08:43] * Joins: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp)
- # [08:43] * Joins: tommyliu (~tommyliu@li407-70.members.linode.com)
- # [08:45] * Quits: tommyliu (~tommyliu@li407-70.members.linode.com) (Remote host closed the connection)
- # [08:48] * Quits: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp) (Ping timeout: 245 seconds)
- # [08:52] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
- # [08:56] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
- # [09:06] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [09:08] * Joins: jdaggett (~jdaggett@ad056175.dynamic.ppp.asahi-net.or.jp)
- # [09:10] * Joins: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp)
- # [09:11] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
- # [09:11] * Joins: hasather (~hasather@80.91.33.141)
- # [09:15] * Joins: laurensclaessen (~laurenscl@91.183.84.141)
- # [09:17] * Joins: Lachy (~Lachy@213.166.174.2)
- # [09:22] * Joins: booly-yam-6137 (~cinch@80.74.98.150)
- # [09:31] * Quits: plutoniix (~plutoniix@119.63.87.222) (Ping timeout: 255 seconds)
- # [09:33] * Joins: danbri (~Adium@host86-191-96-32.range86-191.btcentralplus.com)
- # [09:34] * Joins: Ms2ger (~Ms2ger@91.182.16.148)
- # [09:35] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: Textual IRC Client: www.textualapp.com)
- # [09:36] * Joins: Mso150 (~ctlM@217.118.64.40)
- # [09:37] * Joins: zcorpan (~zcorpan@ip-200.t2.se.opera.com)
- # [09:37] * Quits: psy_ (~psy@103.6.159.170) (Ping timeout: 245 seconds)
- # [09:48] * Quits: Mso150 (~ctlM@217.118.64.40) (Ping timeout: 255 seconds)
- # [10:03] * Joins: calvaris (~calvaris@fanzine.igalia.com)
- # [10:03] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [10:03] * Joins: darobin (~darobin@159.180.228.142)
- # [10:11] * Quits: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com) (Ping timeout: 244 seconds)
- # [10:13] * Joins: zcorpan_ (~zcorpan@ip-200.t2.se.opera.com)
- # [10:16] * Quits: zcorpan (~zcorpan@ip-200.t2.se.opera.com) (Ping timeout: 256 seconds)
- # [10:20] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [10:25] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 276 seconds)
- # [10:30] * Joins: plutoniix (~plutoniix@119.63.87.222)
- # [10:37] * Joins: jochen__ (jochen@nat/google/x-mitdaitxzgkgvbri)
- # [10:41] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
- # [10:42] * Quits: aretecode (~aretecode@50.23.131.206-static.reverse.softlayer.com) (Read error: Connection reset by peer)
- # [10:44] * Quits: tantek (~tantek@70.36.197.247) (Quit: tantek)
- # [10:47] * Joins: zcorpan (~zcorpan@ip-200.t2.se.opera.com)
- # [10:47] * Quits: zcorpan_ (~zcorpan@ip-200.t2.se.opera.com) (Read error: Connection reset by peer)
- # [10:55] * Joins: aretecode (~aretecode@50.23.131.206-static.reverse.softlayer.com)
- # [10:56] * Joins: ehsan__ (~ehsan@24-212-206-173.cable.teksavvy.com)
- # [11:01] * Quits: ehsan__ (~ehsan@24-212-206-173.cable.teksavvy.com) (Ping timeout: 240 seconds)
- # [11:06] * Joins: espadrine (~ttyl@LMontsouris-656-1-2-84.w80-12.abo.wanadoo.fr)
- # [11:07] * Quits: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon) (Quit: Connection closed for inactivity)
- # [11:20] * Joins: Livadi (~julien@195.171.203.84)
- # [11:20] * Joins: patrykn (~patrykn@195.171.203.84)
- # [11:21] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [11:25] * Joins: wilsonpage (~wilsonpag@2001:450:1d:224:c439:e670:a4ba:5a51)
- # [11:25] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 245 seconds)
- # [11:28] * Joins: psy_ (~psy@182.74.25.22)
- # [11:28] * Quits: psy_ (~psy@182.74.25.22) (Max SendQ exceeded)
- # [11:29] * Joins: psy_ (~psy@182.74.25.22)
- # [11:32] * Quits: laurensclaessen (~laurenscl@91.183.84.141) (Remote host closed the connection)
- # [11:36] <annevk> I don't really understand jQuery
- # [11:36] <annevk> $("div").replaceWith([$("div"), "<b>test</b>"])
- # [11:37] <annevk> Gives you "<b>test</b>", loses the <div> somehow...
- # [11:37] <Ms2ger> window.$ = do_what_i_mean
- # [11:37] <annevk> If you remove ', "<b>test</b>"' however, the <div> stays...
- # [11:37] <annevk> Ms2ger: any ideas how to reply to that oldNode.replaceWith() edge case thread?
- # [11:38] * Joins: laurensclaessen (~laurenscl@91.183.84.141)
- # [11:38] <Ms2ger> I've ignored it
- # [11:39] <annevk> Ms2ger: that's not a great way to deal with feedback
- # [11:40] * Quits: plutoniix (~plutoniix@119.63.87.222) (Ping timeout: 240 seconds)
- # [11:40] <annevk> Ms2ger: also, I think those algorithms might in fact have some issues
- # [11:40] <Ms2ger> That's your job :)
- # [11:44] * Joins: satazor (~satazor@37.189.3.135)
- # [11:47] * Quits: satazor (~satazor@37.189.3.135) (Remote host closed the connection)
- # [11:47] * Joins: satazor (~satazor@37.189.3.135)
- # [11:55] * Quits: sarri (~sari@unaffiliated/sarri) (Ping timeout: 264 seconds)
- # [11:56] * Quits: Zebra111 (~quassel@sydnns0115w-156057001250.dhcp-dynamic.FibreOp.ns.bellaliant.net) (Remote host closed the connection)
- # [11:56] * Joins: sarri (~sari@unaffiliated/sarri)
- # [12:01] * Joins: Zebra111 (~quassel@sydnns0115w-156057001250.dhcp-dynamic.FibreOp.ns.bellaliant.net)
- # [12:02] * Quits: booly-yam-6137 (~cinch@80.74.98.150) (Ping timeout: 264 seconds)
- # [12:06] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 265 seconds)
- # [12:10] * Quits: tripu (~tripu@2001:200:0:8805:8dae:8a45:233e:41c7) (Ping timeout: 265 seconds)
- # [12:11] * Joins: GuidoBouman (~GuidoBoum@37.153.217.1)
- # [12:13] <zcorpan> annevk: seems like a bug to remove the div there
- # [12:15] * Joins: adactio (~adactio@212.42.170.121)
- # [12:16] * Joins: zcorpan_ (~zcorpan@ip-200.t2.se.opera.com)
- # [12:17] * Joins: Kolombiken (~Adium@94.137.124.2)
- # [12:17] * Joins: mpt (~mpt@2001:67c:1560:a003:acbf:6797:61c3:2572)
- # [12:17] * Quits: mpt (~mpt@2001:67c:1560:a003:acbf:6797:61c3:2572) (Changing host)
- # [12:17] * Joins: mpt (~mpt@canonical/mpt)
- # [12:19] * Quits: zcorpan (~zcorpan@ip-200.t2.se.opera.com) (Ping timeout: 245 seconds)
- # [12:20] * Joins: frivoal_ (~frivoal@cm-84.211.98.39.getinternet.no)
- # [12:22] <jgraham> Anyone know if the reftest.list files in CSS are actually correct?
- # [12:22] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Ping timeout: 245 seconds)
- # [12:27] * Quits: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek) (Ping timeout: 245 seconds)
- # [12:27] * Quits: GuidoBouman (~GuidoBoum@37.153.217.1) (Quit: Be back later ...)
- # [12:28] <jgraham> Oh, they seem to be generated so I'll assume they are
- # [12:37] * Joins: booly-yam-6137 (~cinch@80.74.98.150)
- # [12:37] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
- # [12:44] * Joins: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si)
- # [12:46] * Joins: GuidoBouman (~GuidoBoum@37.153.217.1)
- # [12:47] <GuidoBouman> Are Flexbox questions allowed here as well? ^_^
- # [12:48] <SimonSapin> jgraham: correct how?
- # [12:50] * Quits: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si) (Ping timeout: 252 seconds)
- # [12:55] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
- # [12:56] * Joins: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek)
- # [12:56] * Joins: hasather (~hasather@80.91.33.141)
- # [12:59] <annevk> zcorpan_: should after() / before() / replaceWith() all work the same if you pass in the context object?
- # [12:59] <annevk> zcorpan_: suggestions welcome in that thread
- # [13:01] * Joins: abinader (sid21713@gateway/web/irccloud.com/x-rhgqvovughjuxxir)
- # [13:03] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
- # [13:03] * Joins: hasather (~hasather@80.91.33.141)
- # [13:04] <zcorpan_> annevk: i think jquery ignores the context node when it appears in an array for after/before/replaceWith
- # [13:05] <zcorpan_> http://jsbin.com/cunejumepo/1/edit
- # [13:07] <zcorpan_> what is more valuable, consistency with insertBefore etc, or with jQuery, being easier to debug mistakes, addressing more use cases?
- # [13:09] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [13:12] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
- # [13:12] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
- # [13:12] * Joins: scor (~scor@drupal.org/user/52142/view)
- # [13:14] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
- # [13:14] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 256 seconds)
- # [13:24] <jgraham> SimonSapin: Correct in the sense of "not incorrect" :)
- # [13:24] <jgraham> e.g. if they were hand-written files that didn't get updated regularly
- # [13:25] <SimonSapin> I don’t know
- # [13:25] * Quits: zcorpan_ (~zcorpan@ip-200.t2.se.opera.com) (Read error: Connection reset by peer)
- # [13:25] * Joins: zcorpan (~zcorpan@ip-200.t2.se.opera.com)
- # [13:25] <jgraham> OK
- # [13:25] <annevk> zcorpan: speed and simplicity were some of the original requirements
- # [13:28] <zcorpan> annevk: ok. i think i'm the wrong person to have an opinion on what is better here
- # [13:32] * Quits: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek) (Ping timeout: 265 seconds)
- # [13:41] * Joins: benjamingr (uid23465@gateway/web/irccloud.com/x-hyaxhvkxmxgwchwb)
- # [13:45] * Joins: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek)
- # [13:46] * Joins: ehsan__ (~ehsan@24-212-206-173.cable.teksavvy.com)
- # [13:48] * Quits: hswolff (~hswolff@cpe-74-68-123-30.nyc.res.rr.com) (Ping timeout: 264 seconds)
- # [13:50] * Joins: hswolff (~hswolff@cpe-74-68-123-30.nyc.res.rr.com)
- # [13:50] * Quits: ehsan__ (~ehsan@24-212-206-173.cable.teksavvy.com) (Ping timeout: 245 seconds)
- # [13:54] * Joins: plutoniix (~plutoniix@node-d31.pool-125-24.dynamic.totbb.net)
- # [13:59] <JakeA> annevk: I'm having to duplicate the about:blank handling from https://html.spec.whatwg.org/multipage/browsers.html#dom-open for cliens.openWindow() - is it appropiate to file a bug with the HTML spec asking for this to be abstracted?
- # [14:00] <annevk> JakeA: yeah, make it clear what you need though
- # [14:00] <JakeA> shall do
- # [14:00] <JakeA> cheers!
- # [14:00] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 245 seconds)
- # [14:08] * Quits: gsnedders (~gsnedders@5.2.16.23) (Ping timeout: 265 seconds)
- # [14:10] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [14:15] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 256 seconds)
- # [14:20] * Joins: tripu (~tripu@p13127-ipngn10901marunouchi.tokyo.ocn.ne.jp)
- # [14:23] * Quits: satazor (~satazor@37.189.3.135) (Remote host closed the connection)
- # [14:24] * Joins: gsnedders (~gsnedders@5.2.16.23)
- # [14:24] * Joins: scor (scor@drupal.org/user/52142/view)
- # [14:42] <annevk> JakeA: did you see the bug I copied you on?
- # [14:43] <annevk> JakeA: I can't really figure out how to make service workers not observable...
- # [14:43] <annevk> JakeA: even ev.default() will have some effect (though it's unclear what that should be)
- # [14:44] <JakeA> annevk: which bug sorry?
- # [14:45] * Quits: Ducki (~Ducki@191.233.66.1) (Quit: Leaving)
- # [14:45] * Quits: zcorpan (~zcorpan@ip-200.t2.se.opera.com) (Read error: Connection reset by peer)
- # [14:45] * Joins: zcorpan (~zcorpan@ip-200.t2.se.opera.com)
- # [14:47] <annevk> JakeA: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27524
- # [14:47] <JakeA> ta
- # [14:48] * Quits: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek) (Ping timeout: 245 seconds)
- # [14:53] <wanderview> JakeA: annevk: if a document does a network request, triggers a SW fetch event, SW starts a different fetch() or cache.add().... and then the original document navigates away before the SW network requests finish... should those requests triggered from the SW fetch event be canceled or completed?
- # [14:54] <annevk> wanderview: I'm not sure what should happen to the FetchEvent instance, but the fetch() and cache.add() should succeed I would think
- # [14:54] <annevk> wanderview: we don't want to have to traverse the calling stack
- # [14:55] <wanderview> annevk: well, in gecko we have the concept of a "load group"... if we share the load group with the document, then they will get canceled... don't think we need to "traverse the calling stack", but maybe I don't understand what you mean
- # [14:55] <wanderview> right now we don't share the document load group directly with the service worker, though
- # [14:55] <wanderview> annevk: sorry, forgot to CC you on this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1122917
- # [14:56] <JakeA> annevk: wanderview: I took a stab at this over in https://github.com/slightlyoff/ServiceWorker/issues/592#issuecomment-68853209
- # [14:58] <wanderview> JakeA: I think that works... basically don't cancel the network request, but abort any resulting stream
- # [14:58] <wanderview> JakeA: and sorry... I read the later comments there, but somehow missed your comment
- # [14:59] * Joins: mven (~textual@32.97.110.56)
- # [14:59] <JakeA> wanderview: No worries! My comment was just a guess, but we don't really know if the request was associated with the fetch event until that point
- # [15:00] <annevk> wanderview: I don't like this "load group" concept as it's not part of any spec, but I guess we need to define something like it at some point
- # [15:00] <wanderview> JakeA: yea... since there can be multiple fetch events in flight at once... it seems we have to wait for resolveWith()
- # [15:00] <annevk> wanderview: but given a document A and a service worker SW, they should probably never share a load group, except maybe for "default" cases, where it is a bit unclear how those should work
- # [15:00] <wanderview> annevk: well... load group is a gecko implementation detail... doesn't have to be specifically in the spec... and its kind of hard to work with
- # [15:01] <annevk> wanderview: yeah, well we need a concept in specs of all fetches associated with a global
- # [15:01] <annevk> wanderview: for various reasons
- # [15:01] <JakeA> annevk: event.default() differs from fetch(event.request) in that it'll return redirects that'll be processed by the fetch spec without further SW interaction right? What does the synchronous part do?
- # [15:02] <wanderview> annevk: in the event.default() case... gecko treats the load as being performed by the document (with its load group), not the SW...
- # [15:02] <wanderview> synchronous part?
- # [15:02] <annevk> JakeA: see the last comment
- # [15:02] <JakeA> wanderview: sorry, crossing the streams a little, I'm talking about https://www.w3.org/Bugs/Public/show_bug.cgi?id=27524
- # [15:03] <annevk> wanderview: that is sort of what the spec says for event.default() as well, however, what's unclear is how we deliver notifications to both globals
- # [15:04] <wanderview> annevk: I didn't realize the SW got any more events for that fetch event() once it did event.default()... or is that something we want to change?
- # [15:05] <annevk> wanderview: how does the SW get a Response object out of event.default() if not for some kind of queued task from the network layer?
- # [15:06] <annevk> wanderview: and how do we maintain progress updates to the document at the same time?
- # [15:06] <JakeA> Ohhh, I think I'm starting to understand
- # [15:06] <annevk> wanderview: seems like it would require a very special path
- # [15:06] <wanderview> annevk: ah... I missed that it does that! :-) for some reason I was thinking event.default() basically just sent it back to document... but I guess thats responseWith() using no argument
- # [15:07] <wanderview> or maybe I'm confused still
- # [15:08] <JakeA> annevk: What if event.default() called fetch in a way that would give it back redirects (opaque if needed), and they're sent back to the original fetch which handles the redirects and doesn't call back into the SW
- # [15:08] <JakeA> Is that observable?
- # [15:08] * Quits: psy_ (~psy@182.74.25.22) (Quit: Leaving)
- # [15:09] <JakeA> As far as I can remember event.default() was there pave over the redirect behaviour of a new fetch call consuming redirects
- # [15:10] <wanderview> I guess there is no respondWith()... you have to do event.respondWith(event.default())
- # [15:10] <annevk> JakeA: yeah, download progress is still gone
- # [15:11] <JakeA> annevk: the response is passed back to the browser before the stream is read
- # [15:11] <annevk> JakeA: you might get the "progress" from sending it from SW to A, but the idea is that you get the progress from what actually happens network-wise (at least when using .default())
- # [15:11] * Quits: jacobolu_ (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
- # [15:12] <annevk> JakeA: that is true
- # [15:12] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
- # [15:12] <wanderview> annevk: I'm guessing on the impl side we can make the progress work... but not sure how it should be spec'd
- # [15:13] <JakeA> If progress is judged by content-length headers & the stream, doesn't it just work?
- # [15:13] <annevk> I doubt it "just" works :-)
- # [15:13] <annevk> For one thing there's that bug
- # [15:15] <JakeA> That's my specing style. 1. Just, make it happen. 2. Srs have you even started yet? 3. Return correct response.
- # [15:15] <annevk> heh
- # [15:16] <JakeA> annevk: If event.default() made a new fetch, which would return raw redirects, then pass those back to the original fetch, doesn't that get us out of having to go from fetchA to SW to fetchA and back to SW?
- # [15:16] * Joins: decotii (~decotii@hq.croscon.com)
- # [15:16] <wanderview> annevk: in gecko we have the concept of a "network callback" which can be set on a load group to effect many requests, or just on a single network request... progress is communicated back to the document that way (I think)... so we can, in theory, set the progress callback for the document while performing the fetch in the SW context
- # [15:16] <annevk> So yeah, redirects were observable, anything else?
- # [15:17] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 265 seconds)
- # [15:18] <annevk> JakeA: then Fetch needs to know SW used default()
- # [15:18] <annevk> JakeA: see https://fetch.spec.whatwg.org/#http-fetch for how that would fall apart now
- # [15:18] <JakeA> annevk: I think that's just a side effect of using event.default(). Things don't change from the document's perspective though, as the redirects are handled by the original fetch, baseurls are fine
- # [15:18] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-fgpdcteegoebaesv)
- # [15:18] <JakeA> annevk: Don't see how fetch needs to be aware of event.default(), although I've probably forgotten why
- # [15:19] <annevk> JakeA: if default() does not handle redirects you can't store it in the cache as easily anymore
- # [15:19] <wanderview> annevk: JakeA: sorry if this was discussed and I missed... but in the case where SW calls respondWith() with a different fetch() or cache.add()... should the document still get progress updates? is this unique to default()?
- # [15:20] <annevk> JakeA: also HTTP Fetch cannot block on all opaque stuff anymore and has to inspect if it's a redirect
- # [15:20] <annevk> wanderview: it's a bit unclear
- # [15:21] <wanderview> as a user... I imagine I would expect to still get progress in those cases
- # [15:21] <annevk> wanderview: and I think you do given that the progress is mostly about the stream anyway
- # [15:22] <annevk> wanderview: though you wouldn't if someone consumed the whole stream in the SW and then constructed a response and then passed that back
- # [15:22] <wanderview> annevk: so the terminology we use in our impl is that there is a "progress event sink"... can that be spec'd? so when event.respondWith(resp) is called, the UA sets the progress event sink for the associated document on the response?
- # [15:23] <wanderview> and event.default() starts with the documents progress event sink
- # [15:23] <JakeA> wanderview: the browser should use the response it gets via respondWith to determine progress. So event.respondWith(fetch(url)) would show progress, event.respondWith(fetch(url).then(r => r,text()).then(t => new Response(t))) wouldn't
- # [15:23] <annevk> Yeah, what JakeA says the specification defines now, that'd be hard to change
- # [15:23] <annevk> JakeA: I don't see a way around Fetch needing to know about default()
- # [15:24] <wanderview> ok, I think we have an impl bug... because I don't think we report progress in that case
- # [15:24] * wanderview goes to bugzilla.
- # [15:24] <annevk> JakeA: and it knows about default(), you might as well follow all the redirects in SW...
- # [15:24] * Joins: satazor (~satazor@37.189.3.135)
- # [15:24] <annevk> JakeA: (so you can store the response in the cache)
- # [15:25] <annevk> wanderview: progress events are based on the stream that comes from the network; from the document's perspective, the network is the SW; from the SW, it's the actual network
- # [15:25] <JakeA> annevk: we talked about the SW being able to pass a response back that contained something to say "btw, treat the base url as [whatever]" to work around this
- # [15:25] <JakeA> I think it was dismissed as too hacky at the time
- # [15:25] <JakeA> but maybe it's simpler?
- # [15:25] <annevk> wanderview: the confusing bit here is that the stream is shared and at some point probably cloned so it can be read simultaneously
- # [15:25] <wanderview> annevk: yea... but our current impl does not report progress (afaict) for event.respondWith(fetch(url))
- # [15:27] <JakeA> wanderview: fwiw, I don't Chrome does it with caches. Don't think those stream yet.
- # [15:27] <annevk> JakeA: so we'd annotate the response from a .default() somehow?
- # [15:27] <annevk> JakeA: as meaning "imagine you followed a redirect to get here"
- # [15:27] <JakeA> annevk: yeah
- # [15:27] <annevk> JakeA: it is pretty hacky
- # [15:27] <JakeA> :D
- # [15:28] <JakeA> less hacky than trying to loop back into the SW?
- # [15:28] <annevk> JakeA: the alternative is that you don't get anything out of a .default()
- # [15:28] <annevk> JakeA: that it's exactly identical to letting the request fly
- # [15:29] <annevk> JakeA: sorry, to not do anything with the event
- # [15:29] <annevk> JakeA: because now it is a bit different from not doing anything with the event, which is somewhat weird
- # [15:30] * Quits: satazor (~satazor@37.189.3.135) (Ping timeout: 272 seconds)
- # [15:30] * Quits: zcorpan (~zcorpan@ip-200.t2.se.opera.com) (Remote host closed the connection)
- # [15:31] * Joins: ehsan (~ehsan@24-212-206-173.cable.teksavvy.com)
- # [15:32] <JakeA> annevk: I think event.default().catch(getAFallbackFromCache) needed
- # [15:33] * Joins: TallTed (~Thud@63.119.36.36)
- # [15:35] <JakeA> From memory, event.default() was there to let the browser do it's normal thing, but still offer recovery from failure. Caching result is nice too
- # [15:36] <JakeA> annevk: if event.default() resolves with the eventual response, it isn't *ideal* for caching as you'd be caching it against the original request url
- # [15:36] <JakeA> So your base urls would be off next time you get from the cache
- # [15:37] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
- # [15:37] <JakeA> (unless it had Jake's patented super magic "use this as the base url" hack)
- # [15:39] * Quits: sarri (~sari@unaffiliated/sarri) (Ping timeout: 256 seconds)
- # [15:40] * Joins: sarri (~sari@unaffiliated/sarri)
- # [15:41] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [15:42] <wanderview> JakeA: yea... the annoying thing is we don't get stuff like progress events for free with data streams in gecko... network streams are completely different than other streams :-\
- # [15:43] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
- # [15:43] * Quits: jsx (uid48919@fsf/intern/jsx) (Quit: Connection closed for inactivity)
- # [15:43] <annevk> JakeA: should we instead drop default() and put a way to mutate a response into requiring a synthetic redirect?
- # [15:44] <JakeA> annevk: I'm very interested in that. I've been wanting to kill .default() forever.
- # [15:45] <annevk> JakeA: I know :-)
- # [15:45] <annevk> JakeA: open a ticket?
- # [15:45] <JakeA> Shall do
- # [15:45] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 245 seconds)
- # [15:47] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 255 seconds)
- # [15:49] * Joins: zcorpan_ (~zcorpan@ip-200.t2.se.opera.com)
- # [15:55] * Quits: zcorpan_ (~zcorpan@ip-200.t2.se.opera.com) (Remote host closed the connection)
- # [15:56] * Joins: hemanth (~hemanth@122.166.173.192)
- # [16:01] * Joins: ttepasse (~ttepasse@ip-178-201-128-201.hsi08.unitymediagroup.de)
- # [16:01] * Quits: hemanth (~hemanth@122.166.173.192) (Client Quit)
- # [16:01] * Joins: tommyliu (~tommyliu@116.247.108.182)
- # [16:03] * Joins: satazor (~satazor@37.189.3.135)
- # [16:06] <JakeA> annevk: https://github.com/slightlyoff/ServiceWorker/issues/607
- # [16:15] * Joins: zcorpan (~zcorpan@ip-200.t2.se.opera.com)
- # [16:18] * Joins: hemanth_ (~hemanth@122.166.173.192)
- # [16:20] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [16:22] * Quits: tommyliu (~tommyliu@116.247.108.182) (Read error: Connection reset by peer)
- # [16:23] * Joins: tommyliu (~tommyliu@li446-72.members.linode.com)
- # [16:26] * Joins: eric_carlson (~ericc@17.202.49.94)
- # [16:27] * Quits: ttepasse (~ttepasse@ip-178-201-128-201.hsi08.unitymediagroup.de) (Read error: Connection reset by peer)
- # [16:28] * Joins: ttepasse (~ttepasse@ip-178-201-128-201.hsi08.unitymediagroup.de)
- # [16:28] * Joins: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net)
- # [16:30] * Quits: danbri (~Adium@host86-191-96-32.range86-191.btcentralplus.com) (Ping timeout: 264 seconds)
- # [16:30] * Joins: psy_ (~psy@103.6.159.170)
- # [16:30] * Quits: dexter_yy (~dexteryy@221.216.52.141) (Ping timeout: 245 seconds)
- # [16:31] * Joins: danbri (~Adium@host86-191-96-32.range86-191.btcentralplus.com)
- # [16:33] * Quits: decotii (~decotii@hq.croscon.com) (Quit: Leaving)
- # [16:34] * Joins: zecho (~zecho@204.77.45.99)
- # [16:37] * Quits: booly-yam-6137 (~cinch@80.74.98.150) (Ping timeout: 255 seconds)
- # [16:37] <JakeA> annevk: speccing Client. Multiple methods return a client object, but client doesn't have a constructor (although I guess it could), where would I define the construction steps? As in, taking an environment settings object and setting all the properties etc
- # [16:43] * Quits: satazor (~satazor@37.189.3.135) (Read error: No route to host)
- # [16:43] * Joins: booly-yam-6137 (~cinch@80.74.98.150)
- # [16:43] * Joins: satazor (~satazor@37.189.3.135)
- # [16:46] * Quits: darobin (~darobin@159.180.228.142) (Remote host closed the connection)
- # [16:54] * Quits: zecho (~zecho@204.77.45.99) (Remote host closed the connection)
- # [16:55] * Joins: zecho (~zecho@199.17.246.199)
- # [17:00] * Quits: booly-yam-6137 (~cinch@80.74.98.150) (Ping timeout: 256 seconds)
- # [17:09] * Quits: ehsan (~ehsan@24-212-206-173.cable.teksavvy.com) (Remote host closed the connection)
- # [17:11] * Quits: kapil__ (uid36151@gateway/web/irccloud.com/x-fwgsuuudlmkilnik) (Quit: Connection closed for inactivity)
- # [17:15] * Joins: ivanc (~ivanc@hq.croscon.com)
- # [17:15] * Quits: satazor (~satazor@37.189.3.135) (Read error: No route to host)
- # [17:15] * Joins: satazor (~satazor@37.189.3.135)
- # [17:19] <annevk> JakeA: some prose
- # [17:20] <annevk> JakeA: "To /create a Client object/, run these steps:"
- # [17:22] * Quits: zcorpan (~zcorpan@ip-200.t2.se.opera.com) (Remote host closed the connection)
- # [17:24] <JakeA> annevk: Thanks. Also, I'm hitting the problem I think you tried to explain to me in the past. If the client is a SharedWorker, postMessage doesn't really fit, as SharedWorker doesn't have onmessage (it depends on ports for reasons I've never entirely understood). I guess this is why we should have WindowClient, but then just instances of DedicatedWorker &
- # [17:24] <JakeA> SharedWorker?
- # [17:27] * Joins: zecho_ (~zecho@204.77.45.99)
- # [17:31] * Quits: zecho (~zecho@199.17.246.199) (Ping timeout: 272 seconds)
- # [17:33] * Joins: jsx (uid48919@fsf/intern/jsx)
- # [17:34] * Joins: ehsan (~ehsan@2001:450:1f:224:bdc8:9455:560d:a88e)
- # [17:36] * Quits: satazor (~satazor@37.189.3.135) (Remote host closed the connection)
- # [17:37] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [17:43] * Quits: laurensclaessen (~laurenscl@91.183.84.141)
- # [17:43] * Joins: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
- # [17:44] * Joins: Mso150 (~ctlM@80.83.239.9)
- # [17:44] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
- # [17:45] * Joins: tommyliu_ (~tommyliu@116.247.108.182)
- # [17:49] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 264 seconds)
- # [17:50] * Quits: tommyliu (~tommyliu@li446-72.members.linode.com) (Ping timeout: 264 seconds)
- # [17:51] * Quits: wilsonpage (~wilsonpag@2001:450:1d:224:c439:e670:a4ba:5a51) (Quit: Leaving.)
- # [17:51] * Joins: satazor (~satazor@37.189.3.135)
- # [17:57] <JakeA> Never understood way SharedWorker uses ports the way it does. Why can't it just be sharedWorker.postMessage(…), then the worker can respond via messageEvent.source
- # [17:57] <JakeA> why*
- # [17:58] <caitp> 0
- # [17:59] <Ms2ger> Symmetry?
- # [17:59] <JakeA> Symmetry with what?
- # [18:00] * Joins: tommyliu (~tommyliu@116.247.108.182)
- # [18:00] * Joins: booly-yam-6137 (~cinch@bzq-79-178-15-163.red.bezeqint.net)
- # [18:01] * Quits: tommyliu_ (~tommyliu@116.247.108.182) (Ping timeout: 245 seconds)
- # [18:03] <jgraham> Could be that it was designed with the idea that everyone would be passing around ports as part of some capabilties system, which might skew one's views on good api design
- # [18:04] * Joins: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com)
- # [18:06] * Quits: psy_ (~psy@103.6.159.170) (Quit: Leaving)
- # [18:08] * Joins: Maurice` (copyman@5ED5617C.cm-7-6b.dynamic.ziggo.nl)
- # [18:08] * Quits: Maurice` (copyman@5ED5617C.cm-7-6b.dynamic.ziggo.nl) (Changing host)
- # [18:08] * Joins: Maurice` (copyman@unaffiliated/maurice)
- # [18:12] * Joins: wilsonpage (~wilsonpag@2001:450:1d:224:d0d3:a0ba:9893:c324)
- # [18:16] <annevk> JakeA: wait, does client.postMessage() go to window.onmessage?
- # [18:16] <annevk> JakeA: or to navigator.serviceWorkers...?
- # [18:17] <annevk> JakeA: the way shared worker works is that each worker or document that connects to it gets its own port
- # [18:17] <annevk> JakeA: however, when a shared worker is controlled by a service worker we should not use that API
- # [18:17] <annevk> JakeA: because that is a completely different relationship
- # [18:18] <Ms2ger> annevk, I wonder if there's anything useful in https://github.com/operasoftware/presto-testo/tree/master/imported/peter/unicode/html
- # [18:19] <JakeA> annevk: client.postMessage would go to window.onmessage I thought
- # [18:19] <annevk> Ms2ger: double and ent look redundant
- # [18:20] <annevk> JakeA: ooooh, that's a lot of branching for window.onmessage then...
- # [18:20] <annevk> JakeA: I thought the events would go to the associated ServiceWorker object
- # [18:21] <annevk> Ms2ger: maybe the excess stuff but I suspect we already got that covered elsewhere too
- # [18:21] <Ms2ger> Ok, thanks for looking
- # [18:21] <annevk> JakeA: it seems pretty bad to overload window.onmessage like that
- # [18:22] <JakeA> annevk: navigator.serviceWorker.onmessage? We don't have that right now, but we could. What's the issue with window.onmessage? https://html.spec.whatwg.org/multipage/comms.html#dom-window-postmessage makes it look simple aside from the transferables
- # [18:22] <annevk> JakeA: it's already used for cross-window postMessage
- # [18:23] * Joins: zcorpan (~zcorpan@ip-200.t2.se.opera.com)
- # [18:24] <annevk> JakeA: how can only client have postMessage()? How do you postMessage() from the window?
- # [18:24] <JakeA> annevk: I thought of window-to-window as client-to-client
- # [18:24] <annevk> JakeA: no, so ServiceWorker inherits from Worker
- # [18:25] <annevk> JakeA: and that has both postMessage() and onmessage
- # [18:25] <annevk> JakeA: Client is the other side
- # [18:25] <annevk> JakeA: it only makes sense for those two to talk to each other
- # [18:25] <JakeA> annevk: messageEvent.source.postMessage would post back to serviceWorkerGlobalScope.onmessage
- # [18:25] * JakeA thinks
- # [18:26] * Quits: hemanth_ (~hemanth@122.166.173.192) (Quit: This computer has gone to sleep)
- # [18:27] * Joins: ap (~ap@17.202.44.214)
- # [18:28] <JakeA> annevk: so you were thinking the message would go to (await navigator.serviceWorker.getRegistration()).active?
- # [18:29] <annevk> yeah
- # [18:29] <annevk> that's the only thing that made sense to me and would work for both documents and workers
- # [18:29] <annevk> and would give a somewhat sane API
- # [18:29] <annevk> and be consistent with what we have for workers today
- # [18:30] <annevk> Are you now going to tell me that Chrome implemented something else?
- # [18:30] <JakeA> We haven't implemented clients yet
- # [18:30] <annevk> No messaging at all?
- # [18:31] <JakeA> Window to SW, but won't think we have a way back yet
- # [18:31] <JakeA> I think we need to stop & think about how this stuff works
- # [18:32] <JakeA> registration objects don't feel client-unique to me, so not sure they're a good place for onmessage either
- # [18:33] * zecho_ is now known as zecho
- # [18:33] * Quits: plutoniix (~plutoniix@node-d31.pool-125-24.dynamic.totbb.net) (Ping timeout: 244 seconds)
- # [18:34] <annevk> I guess the only problem is that Client objects are currently designed as non-persistent
- # [18:34] <annevk> That doesn't make for a great message channel receiver
- # [18:35] <annevk> JakeA: I thought registration object was ServiceWorkerRegistration, not ServiceWorker
- # [18:35] <annevk> (I hate the naming)
- # [18:35] * Joins: plutoniix (~plutoniix@node-d31.pool-125-24.dynamic.totbb.net)
- # [18:36] <JakeA> annevk: yes, so (await navigator.serviceWorker.getRegistration()) is a ServiceWorkerRegistration, then .active is a ServiceWorker
- # [18:39] <JakeA> ServiceWorkerRegistration is an origin-level thing rather than a client-specific thing, so getting client-specific message on it, or its properties feels wrong.
- # [18:39] <JakeA> Lemmie write up an issue \o/
- # [18:40] <annevk> JakeA: well, it's the only way to get a reference to a a client's own service worker
- # [18:40] <annevk> JakeA: seems fairly fricking specific to me
- # [18:42] <JakeA> annevk: a client selects a registration, but many clients can select the same registration
- # [18:45] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
- # [18:45] * Quits: zecho (~zecho@204.77.45.99) (Remote host closed the connection)
- # [18:46] * jorendorff_ is now known as jorendorff
- # [18:48] <annevk> JakeA: oh I see what you mean, I had imagined it would go to all of them, but indeed that does not really work
- # [18:48] <annevk> JakeA: okay, so yes, we need something new :/
- # [18:49] * Quits: iandevlin (~iandevlin@dslb-088-078-251-070.088.078.pools.vodafone-ip.de) (Ping timeout: 255 seconds)
- # [18:49] <JakeA> annevk: I think postMessage & serviceWorker has been handwaved all the way :(
- # [18:49] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Read error: Connection reset by peer)
- # [18:49] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
- # [18:50] <JakeA> annevk: It could be navigator.serviceWorker.onmessage for messages from a ServiceWorker. Anyway, will write up a ticket. Thanks for dragging me through it
- # [18:50] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 276 seconds)
- # [18:50] * Joins: hasather (~hasather@80.91.33.141)
- # [18:51] * Quits: tommyliu (~tommyliu@116.247.108.182) (Read error: Connection reset by peer)
- # [18:51] * Joins: tommyliu (~tommyliu@li446-72.members.linode.com)
- # [18:51] * Joins: calvaris (~calvaris@fanzine.igalia.com)
- # [18:52] * Quits: plutoniix (~plutoniix@node-d31.pool-125-24.dynamic.totbb.net) (Ping timeout: 272 seconds)
- # [18:53] * Quits: satazor (~satazor@37.189.3.135) (Read error: No route to host)
- # [18:53] * Joins: satazor (~satazor@37.189.3.135)
- # [18:56] * Quits: adactio (~adactio@212.42.170.121) (Quit: adactio)
- # [18:58] * Quits: tripu (~tripu@p13127-ipngn10901marunouchi.tokyo.ocn.ne.jp) (Ping timeout: 276 seconds)
- # [19:00] * Joins: iandevlin (~iandevlin@dslb-088-078-251-070.088.078.pools.vodafone-ip.de)
- # [19:01] * Quits: wilsonpage (~wilsonpag@2001:450:1d:224:d0d3:a0ba:9893:c324) (Quit: Leaving.)
- # [19:01] * Joins: wilsonpage (~wilsonpag@2001:450:1d:224:d0d3:a0ba:9893:c324)
- # [19:01] * Joins: plutoniix (~plutoniix@node-d31.pool-125-24.dynamic.totbb.net)
- # [19:01] <annevk> JakeA: yeah, the whole "just like shared workers" stuff has been somewhat painful to point through
- # [19:01] <annevk> JakeA: thanks
- # [19:02] <Ms2ger> Do we still like shared workers?
- # [19:03] * Joins: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com)
- # [19:03] * Quits: yoichio (yoichio@nat/google/x-yqkrzkgknhumfhvv) (Quit: Leaving...)
- # [19:03] * Quits: bnicholson (~bnicholso@24.130.60.241) (Quit: This computer has gone to sleep)
- # [19:04] <jgraham> Pretty sure that the answer is "No" for all questions of the form "do we still like X" where X is a past web technology, and "Yes" where X is a future web technology
- # [19:06] * Joins: tommyliu_ (~tommyliu@116.247.108.182)
- # [19:10] * Quits: tommyliu (~tommyliu@li446-72.members.linode.com) (Ping timeout: 276 seconds)
- # [19:11] * Joins: psy_ (~psy@103.6.159.170)
- # [19:12] <caitp> so you're saying there's a chance that opinions might change in 20 years?
- # [19:12] <caitp> goodness
- # [19:13] <jgraham> I'm saying that there's a discontinuity at t=present :p
- # [19:15] * Joins: bnicholson (~bnicholso@corp.mtv2.mozilla.com)
- # [19:16] <JakeA> annevk: different subject, we're starting to look more seriously at background sync. I see FirefoxOS has something that I think was based on early ideas we had https://bugzilla.mozilla.org/show_bug.cgi?id=1018320 - who'd be best to get involved in making it a standard?
- # [19:16] * Quits: satazor (~satazor@37.189.3.135) (Remote host closed the connection)
- # [19:16] <annevk> JakeA: it seems very likely it'll be the same people as service worker
- # [19:16] <annevk> JakeA: not sure we can get time from the Firefox OS folks
- # [19:17] <JakeA> annevk: ok, it'd be good to get their learnings, but I'll sort something out with Jonas & yourself
- # [19:18] * Joins: ambv (~ambv@199.201.64.134)
- # [19:19] <annevk> JakeA: copy overholt
- # [19:19] <annevk> JakeA: he'll know who to talk to
- # [19:19] <JakeA> Ta!
- # [19:23] * Joins: satazor (~satazor@37.189.3.135)
- # [19:25] * Quits: satazor (~satazor@37.189.3.135) (Remote host closed the connection)
- # [19:25] <JakeA> annevk: https://github.com/slightlyoff/ServiceWorker/issues/609
- # [19:25] <JakeA> navigator.serviceWorker.onmessage seems to fit
- # [19:31] * Joins: satazor (~satazor@37.189.3.135)
- # [19:35] * Quits: tommyliu_ (~tommyliu@116.247.108.182) (Remote host closed the connection)
- # [19:40] * Joins: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si)
- # [19:46] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
- # [19:50] * Joins: Mso150_n (~ctlM@80.83.239.14)
- # [19:50] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 255 seconds)
- # [19:51] * Quits: Mso150 (~ctlM@80.83.239.9) (Ping timeout: 245 seconds)
- # [19:52] * Quits: espadrine (~ttyl@LMontsouris-656-1-2-84.w80-12.abo.wanadoo.fr) (Ping timeout: 246 seconds)
- # [19:56] * Joins: zecho (~zecho@204.77.45.99)
- # [19:56] * Quits: satazor (~satazor@37.189.3.135) (Remote host closed the connection)
- # [19:57] * Joins: satazor (~satazor@37.189.3.135)
- # [20:00] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [20:02] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Quit: Ex-Chat)
- # [20:03] * Quits: booly-yam-6137 (~cinch@bzq-79-178-15-163.red.bezeqint.net) (Ping timeout: 246 seconds)
- # [20:04] * Joins: eric_carlson_ (~ericc@17.114.217.57)
- # [20:04] * Quits: mven (~textual@32.97.110.56) (Quit: Textual IRC Client: www.textualapp.com)
- # [20:06] * Quits: eric_carlson (~ericc@17.202.49.94) (Ping timeout: 256 seconds)
- # [20:06] * Quits: iandevlin (~iandevlin@dslb-088-078-251-070.088.078.pools.vodafone-ip.de) (Quit: Nettalk6 - www.ntalk.de)
- # [20:08] * Quits: eric_carlson_ (~ericc@17.114.217.57) (Ping timeout: 244 seconds)
- # [20:09] * Quits: satazor (~satazor@37.189.3.135) (Remote host closed the connection)
- # [20:09] * Joins: eric_carlson (~ericc@17.245.25.10)
- # [20:10] * Quits: zecho (~zecho@204.77.45.99) (Remote host closed the connection)
- # [20:17] * Quits: GuidoBouman (~GuidoBoum@37.153.217.1) (Quit: Be back later ...)
- # [20:17] * Joins: kuatsure (~kuatsure@64.56.115.10)
- # [20:19] * Quits: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [20:31] * Joins: cub512 (~cub512@67.23.114.6)
- # [20:33] * Quits: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si) (Quit: Leaving.)
- # [20:33] * Joins: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek)
- # [20:36] * Quits: cub512 (~cub512@67.23.114.6)
- # [20:45] * Joins: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.cpe.webspeed.dk)
- # [20:46] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
- # [20:52] * Quits: nicolasbadia (~nicolasba@hue38-1-78-209-78-115.fbx.proxad.net) (Quit: nicolasbadia)
- # [20:52] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 246 seconds)
- # [20:57] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
- # [20:57] * Joins: darobin (~darobin@2a01:e34:ed05:d180:548c:259e:e576:317d)
- # [21:01] * Quits: eric_carlson (~ericc@17.245.25.10) (Quit: eric_carlson)
- # [21:02] * Joins: jyasskin (jyasskin@nat/google/x-kwdwqxzlvqegpxqb)
- # [21:04] * Quits: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
- # [21:05] * Quits: frivoal_ (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
- # [21:06] * Joins: dbaron (~dbaron@2620:101:80fb:224:8859:f075:e6fa:6dd2)
- # [21:06] * Quits: ehsan (~ehsan@2001:450:1f:224:bdc8:9455:560d:a88e) (Quit: Leaving...)
- # [21:07] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
- # [21:08] <Domenic> annevk: I managed to confuse myself about "queue a task" and microtasks and such again. What do you think would happen in the following?
- # [21:08] <Domenic> 1. Queue a task to: 1a. resolve the promise p; 1b. fire an event named "foo". Given that I've registered a fulfillment handler on p and a listener for "foo", which fires first?
- # [21:09] <Ms2ger> I think the listener
- # [21:09] <Domenic> At first I thought it'd be "foo" first since events are "synchronous". But then I thought it'd be p first since microtasks fire whenever you transition from UA code to user code.
- # [21:09] <Domenic> hmm
- # [21:09] <Ms2ger> But I have no idea how microtasks work
- # [21:10] <Ms2ger> Do they fire before calling event handlers?
- # [21:10] <Ms2ger> Presumably not, because then you could sniff whether there are event handlers attached for some type
- # [21:10] <Domenic> I ... think so. This might start falling into the unspecced areas :-/. Hixie do you know?
- # [21:10] * Joins: nicolasbadia_ (~nicolasba@hue38-1-78-209-78-115.fbx.proxad.net)
- # [21:16] * Joins: Mso150_n_s (~ctlM@80.83.238.54)
- # [21:16] * Quits: Mso150_n (~ctlM@80.83.239.14) (Ping timeout: 255 seconds)
- # [21:17] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
- # [21:18] * Quits: zcorpan (~zcorpan@ip-200.t2.se.opera.com) (Remote host closed the connection)
- # [21:18] * Joins: zcorpan (~zcorpan@ip-200.t2.se.opera.com)
- # [21:19] <Hixie> Domenic: no microtasks would fire in that case until the first script for the first event listener returned, iirc
- # [21:20] <Domenic> Hixie: hmm OK. So saying "microtasks fire whenever transitioning from UA code to user code" is not really correct of me to say then. That's good to know.
- # [21:24] * Quits: nicolasbadia_ (~nicolasba@hue38-1-78-209-78-115.fbx.proxad.net) (Quit: nicolasbadia_)
- # [21:29] * Joins: woebtz (~woebtz@12.36.17.197)
- # [21:30] <Hixie> no it's much more specific than that
- # [21:32] * Joins: dexteryy (~dexteryy@221.216.52.141)
- # [21:32] * Joins: ^esc_ (~esc-ape@178.115.128.195.wireless.dyn.drei.com)
- # [21:34] * Joins: yexela (~yexela@178.214.222.140)
- # [21:35] * Quits: ^esc (~esc-ape@178.115.129.182.wireless.dyn.drei.com) (Ping timeout: 264 seconds)
- # [21:47] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
- # [21:50] * Joins: jamesheston (~jameshest@108-230-76-57.lightspeed.chtnsc.sbcglobal.net)
- # [21:55] * heycam|away is now known as heycam
- # [21:56] * Joins: eric_carlson (~ericc@17.245.25.62)
- # [22:02] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
- # [22:03] * Joins: ihab (~Adium@41.69.106.78)
- # [22:03] * Quits: eric_carlson (~ericc@17.245.25.62) (Quit: eric_carlson)
- # [22:03] * Joins: nicolasbadia (~nicolasba@hue38-1-78-209-78-115.fbx.proxad.net)
- # [22:03] * Quits: Mso150_n_s (~ctlM@80.83.238.54) (Ping timeout: 255 seconds)
- # [22:05] * Joins: karlcow (~karl@nerval.la-grange.net)
- # [22:07] * Parts: ihab (~Adium@41.69.106.78)
- # [22:10] * Joins: weinig (~weinig@17.245.30.235)
- # [22:11] * Quits: zcorpan (~zcorpan@ip-200.t2.se.opera.com) (Remote host closed the connection)
- # [22:26] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
- # [22:28] * Quits: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp) (Remote host closed the connection)
- # [22:28] * Joins: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp)
- # [22:32] * Quits: myakura (~myakura@FL1-125-197-192-76.tky.mesh.ad.jp) (Ping timeout: 245 seconds)
- # [22:36] * Quits: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
- # [22:36] * Joins: jsbell (jsbell@nat/google/x-edebykjvxevlgulg)
- # [22:38] * Joins: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com)
- # [22:38] * Quits: darobin (~darobin@2a01:e34:ed05:d180:548c:259e:e576:317d) (Remote host closed the connection)
- # [22:39] * Quits: jamesheston (~jameshest@108-230-76-57.lightspeed.chtnsc.sbcglobal.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # [22:40] <annevk> Domenic: the event goes first
- # [22:40] <annevk> Domenic: microtasks run end-of-task
- # [22:40] <Domenic> got it :)
- # [22:43] * Quits: ttepasse (~ttepasse@ip-178-201-128-201.hsi08.unitymediagroup.de) (Quit: s)
- # [22:47] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
- # [22:53] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 245 seconds)
- # [22:55] * Quits: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
- # [22:55] * Joins: karlcow (~karl@nerval.la-grange.net)
- # [23:02] * Quits: ap (~ap@17.202.44.214) (Ping timeout: 245 seconds)
- # [23:02] * Quits: TallTed (~Thud@63.119.36.36)
- # [23:02] * Quits: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.cpe.webspeed.dk) (Ping timeout: 245 seconds)
- # [23:04] * Joins: ap (~ap@17.114.217.173)
- # [23:05] * Joins: rniwa (~rniwa@17.202.43.222)
- # [23:10] <Ms2ger> annevk, a few changes for you in https://critic.hoppipolla.co.uk/r/3723
- # [23:12] * Joins: zcorpan (~zcorpan@ip-200.t2.se.opera.com)
- # [23:13] * Joins: eric_carlson (~ericc@17.202.49.94)
- # [23:14] * Quits: yexela (~yexela@178.214.222.140) (Ping timeout: 265 seconds)
- # [23:17] * Quits: Maurice` (copyman@unaffiliated/maurice)
- # [23:17] * Joins: jwalden (~waldo@c-50-168-55-219.hsd1.ca.comcast.net)
- # [23:18] * Quits: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek) (Quit: Leaving.)
- # [23:19] * Joins: ihab (~Adium@41.69.106.78)
- # [23:19] * Quits: ihab (~Adium@41.69.106.78) (Client Quit)
- # [23:30] * Quits: jyasskin (jyasskin@nat/google/x-kwdwqxzlvqegpxqb) (Read error: Connection reset by peer)
- # [23:31] * Joins: jyasskin (jyasskin@nat/google/x-oycdyxzxdnrwccyl)
- # [23:36] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
- # [23:38] * Quits: plutoniix (~plutoniix@node-d31.pool-125-24.dynamic.totbb.net) (Quit: จรลี จรลา)
- # [23:40] * Quits: kuatsure (~kuatsure@64.56.115.10) (Ping timeout: 252 seconds)
- # [23:44] * Quits: weinig (~weinig@17.245.30.235) (Quit: weinig)
- # [23:44] <Ms2ger> zcorpan, fyi https://bugzilla.mozilla.org/show_bug.cgi?id=1122897
- # [23:45] * Quits: Ms2ger (~Ms2ger@91.182.16.148) (Quit: nn)
- # [23:49] * Joins: weinig (~weinig@17.245.30.235)
- # [23:49] * Quits: eric_carlson (~ericc@17.202.49.94) (Quit: eric_carlson)
- # [23:50] * Joins: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
- # [23:52] * Quits: jdaggett (~jdaggett@ad056175.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
- # [23:54] * Quits: weinig (~weinig@17.245.30.235) (Quit: weinig)
- # Session Close: Wed Jan 21 00:00:00 2015
Previous day, Next day
Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn