Options:
Previous day, Next day
- # Session Start: Mon Mar 30 00:00:00 2015
- # Session Ident: #whatwg
- # [00:01] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
- # [00:01] * Joins: smaug____ (~chatzilla@85-76-73-167-nat.elisa-mobile.fi)
- # [00:08] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
- # [00:08] * Quits: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net) (Remote host closed the connection)
- # [00:14] <Ms2ger> Prettified? Not that I know of
- # [00:16] <gsnedders> aleray: no
- # [00:18] <jgraham> Well I mean it's possible, but you have to write a custom serializer
- # [00:21] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [00:23] <gsnedders> nah, should be doable with a treewalker filter, I think?
- # [00:23] <gsnedders> Depends on how pretty you want, really :)
- # [00:28] <aleray> gsnedders, jgraham Ms2ger typically something like this: http://jsbeautifier.org/
- # [00:31] * Quits: Ms2ger (~Ms2ger@60.219-242-81.adsl-dyn.isp.belgacom.be) (Quit: nn)
- # [00:37] * Quits: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net) (Quit: Leaving)
- # [00:38] * Quits: alrra (uid62345@gateway/web/irccloud.com/x-gmxssrabcwkelusz) (Quit: Connection closed for inactivity)
- # [00:44] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [00:56] <aleray> would be an interesting project. For now I will use the node.js package js-beautify (which seems to be develloping a python module for that)
- # [01:00] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [01:01] * Quits: smaug____ (~chatzilla@85-76-73-167-nat.elisa-mobile.fi) (Ping timeout: 255 seconds)
- # [01:07] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
- # [01:13] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [01:27] * Quits: deltab (~deltab@cpc2-smal2-0-0-cust22.19-1.cable.virginm.net) (Ping timeout: 244 seconds)
- # [01:35] * Joins: deltab (~deltab@cpc2-smal2-0-0-cust22.19-1.cable.virginm.net)
- # [01:42] * Krinkle|detached is now known as Krinkle
- # [01:47] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
- # [01:49] * Joins: jernoble (~jernoble@162.217.73.171)
- # [01:54] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [01:56] * Quits: dshwang (~dshwang@134.134.137.73) (Remote host closed the connection)
- # [02:04] * Quits: aleray (~aleray@91.182.232.29) (Ping timeout: 248 seconds)
- # [02:21] * Quits: eric_carlson (~ericc@c-24-6-239-9.hsd1.ca.comcast.net) (Quit: eric_carlson)
- # [02:29] * Joins: capella-s3 (~yaaic@cpe-24-59-162-151.twcny.res.rr.com)
- # [02:40] * Quits: lilmonkey (~a@pdpc/supporter/professional/riven) (Ping timeout: 252 seconds)
- # [02:42] * Joins: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net)
- # [02:45] * Joins: wartdev (~wartdev@109.255.148.96)
- # [02:48] * Quits: wartdev (~wartdev@109.255.148.96) (Client Quit)
- # [02:49] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
- # [02:49] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Quit: ChatZilla 0.9.91.1 [Firefox 39.0a1/20150329030238])
- # [02:50] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
- # [02:51] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [02:52] * Quits: jernoble (~jernoble@162.217.73.171) (Quit: Computer has gone to sleep.)
- # [03:01] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 255 seconds)
- # [03:03] * Joins: jernoble (~jernoble@162.217.73.171)
- # [03:13] * Quits: jernoble (~jernoble@162.217.73.171) (Quit: Computer has gone to sleep.)
- # [03:15] * Joins: kbx (~kbx@2401:fa00:4:1013:593c:ee82:21a9:bbf9)
- # [03:17] <MikeSmith> anybody know if there's a WebKit implementation bug open for datalist
- # [03:19] <MikeSmith> https://bugs.webkit.org/show_bug.cgi?id=27247
- # [03:19] <MikeSmith> It seems
- # [03:22] <MikeSmith> now myquestion is, what's blocking it
- # [03:30] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
- # [03:36] * Quits: Rastus_Vernon (Rastus_Ver@wikimedia/Rastus-Vernon) (Quit: bye)
- # [03:43] * heycam is now known as heycam|away
- # [03:55] * c74d is now known as Guest7872
- # [03:55] * Quits: Guest7872 (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766) (Read error: Connection reset by peer)
- # [03:58] * Joins: c74d (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766)
- # [04:02] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [04:04] * Joins: Goplat (~goplat@reactos/developer/Goplat)
- # [04:12] * Joins: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net)
- # [04:14] * Joins: KevinMarks__ (~yaaic@2607:fb90:518:1377:b7b4:c937:ce88:1145)
- # [04:14] * Quits: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net) (Remote host closed the connection)
- # [04:14] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 244 seconds)
- # [04:14] * Joins: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net)
- # [04:18] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [04:19] * heycam|away is now known as heycam
- # [04:21] * Quits: KevinMarks__ (~yaaic@2607:fb90:518:1377:b7b4:c937:ce88:1145) (Ping timeout: 265 seconds)
- # [04:23] * Quits: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net) (Remote host closed the connection)
- # [04:24] * Joins: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net)
- # [04:28] * Quits: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net) (Remote host closed the connection)
- # [04:37] * Joins: ohaibbq (~ohaibbq@98.248.65.213)
- # [04:43] * Joins: tripu (~tripu@2001:200:0:8805:4d2f:f601:ad6e:6d15)
- # [04:48] * Quits: newtron (~newtron@75-119-235-26.dsl.teksavvy.com) (Quit: Leaving...)
- # [04:49] * Joins: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net)
- # [04:57] * Joins: ambv (~ambv@199.201.64.2)
- # [04:59] * Quits: ambv (~ambv@199.201.64.2) (Client Quit)
- # [05:05] * Quits: c74d (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766) (Read error: Connection reset by peer)
- # [05:09] * Joins: c74d (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766)
- # [05:16] * Quits: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net) (Remote host closed the connection)
- # [05:53] * Joins: jernoble (~jernoble@162.217.73.171)
- # [05:57] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
- # [05:58] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [06:01] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
- # [06:02] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [06:02] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
- # [06:04] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
- # [06:05] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [06:08] * Quits: jwalden (~waldo@c-68-60-39-249.hsd1.mi.comcast.net) (Quit: ChatZilla 0.9.87-8.1450hg.fc20 [XULRunner 32.0/20140902134853])
- # [06:23] * Quits: tripu (~tripu@2001:200:0:8805:4d2f:f601:ad6e:6d15) (Ping timeout: 265 seconds)
- # [06:25] * Joins: bholley (~bholley@c-24-130-121-49.hsd1.ca.comcast.net)
- # [06:28] * Quits: howitdo (~howitdo@unaffiliated/howitdo) (Ping timeout: 246 seconds)
- # [06:41] * Joins: howitdo (~howitdo@unaffiliated/howitdo)
- # [06:55] * Joins: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com)
- # [06:57] * Joins: tripu (~tripu@2001:200:0:8805:4d2f:f601:ad6e:6d15)
- # [06:58] * Krinkle is now known as Krinkle|detached
- # [07:00] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
- # [07:02] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-dmufsgucdsppwrgz) (Quit: Connection closed for inactivity)
- # [07:05] * Quits: robogoat (~robogoat@c-24-126-240-124.hsd1.ga.comcast.net) (Ping timeout: 246 seconds)
- # [07:10] * Joins: lilmonkey (~a@pdpc/supporter/professional/riven)
- # [07:13] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
- # [07:18] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 252 seconds)
- # [07:24] * Joins: ohaibbq_ (~ohaibbq@2601:9:a80:a8f:b83e:7bb1:252:3f05)
- # [07:24] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
- # [07:25] * Quits: jernoble (~jernoble@162.217.73.171) (Quit: Textual IRC Client: www.textualapp.com)
- # [07:25] * Joins: bholley_ (~bholley@c-24-130-121-49.hsd1.ca.comcast.net)
- # [07:26] * Quits: bholley (~bholley@c-24-130-121-49.hsd1.ca.comcast.net) (Ping timeout: 264 seconds)
- # [07:26] * Quits: ohaibbq (~ohaibbq@98.248.65.213) (Ping timeout: 264 seconds)
- # [07:26] * Quits: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net) (Ping timeout: 264 seconds)
- # [07:27] * Quits: bholley_ (~bholley@c-24-130-121-49.hsd1.ca.comcast.net) (Remote host closed the connection)
- # [07:32] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [07:33] * Joins: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net)
- # [07:34] * Joins: ohaibbq (~ohaibbq@98.248.65.213)
- # [07:34] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [07:35] * heycam is now known as heycam|away
- # [07:36] * Joins: bholley (~bholley@c-24-130-121-49.hsd1.ca.comcast.net)
- # [07:36] * Quits: ohaibbq_ (~ohaibbq@2601:9:a80:a8f:b83e:7bb1:252:3f05) (Ping timeout: 265 seconds)
- # [07:41] * Quits: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com) (Ping timeout: 256 seconds)
- # [07:48] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
- # [07:56] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [08:01] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
- # [08:03] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
- # [08:03] * Joins: benjamingr (uid23465@gateway/web/irccloud.com/x-afqntjgmlywbxikm)
- # [08:05] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
- # [08:09] * Joins: zcorpan (~zcorpan@c-5eeaaaa5-74736162.cust.telenor.se)
- # [08:10] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 250 seconds)
- # [08:15] * Quits: zcorpan (~zcorpan@c-5eeaaaa5-74736162.cust.telenor.se) (Remote host closed the connection)
- # [08:19] * Joins: zcorpan (~zcorpan@c-5eeaaaa5-74736162.cust.telenor.se)
- # [08:20] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [08:21] * Joins: brcweggs (~brcweggs@pool-71-177-224-47.lsanca.fios.verizon.net)
- # [08:30] * Quits: bholley (~bholley@c-24-130-121-49.hsd1.ca.comcast.net) (Quit: ZZZzzz…)
- # [08:31] * Quits: kbx (~kbx@2401:fa00:4:1013:593c:ee82:21a9:bbf9) (Ping timeout: 272 seconds)
- # [08:32] * Quits: ohaibbq (~ohaibbq@98.248.65.213) (Quit: Leaving...)
- # [08:40] * Joins: rc0mbs (~rcombs@rcombs.me)
- # [08:41] * Quits: rcombs (~rcombs@rcombs.me) (Read error: Connection reset by peer)
- # [08:41] * rc0mbs is now known as rcombs
- # [08:42] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
- # [08:46] * Joins: kbx (~kbx@2401:fa00:4:1013:593c:ee82:21a9:bbf9)
- # [08:48] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
- # [08:50] * Joins: markkes (~markkes@62.207.90.201)
- # [08:57] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [08:58] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
- # [09:01] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
- # [09:05] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
- # [09:05] * Joins: alrra (uid62345@gateway/web/irccloud.com/x-uxaqukfaurhvjtiw)
- # [09:06] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [09:08] * Joins: calvaris (~calvaris@fanzine.igalia.com)
- # [09:09] * Quits: brcweggs (~brcweggs@pool-71-177-224-47.lsanca.fios.verizon.net) (Quit: Lingo: www.lingoirc.com)
- # [09:16] * Joins: KevinMarks__ (~yaaic@2607:fb90:519:b69f:d68d:9798:a700:b0fd)
- # [09:19] <annevk> MikeSmith: probably just someone to work on it
- # [09:19] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 272 seconds)
- # [09:23] <MikeSmith> annevk: yeah, seems so
- # [09:24] <MikeSmith> tkent points out that the interactive form validation stuff is in the same state
- # [09:40] * Quits: mpt (~mpt@canonical/mpt) (Remote host closed the connection)
- # [09:43] * Joins: zdobersek (~zan@46.166.188.215)
- # [09:43] * Joins: mpt (~mpt@2001:67c:1560:a003:49e7:478a:4675:2698)
- # [09:43] * Quits: mpt (~mpt@2001:67c:1560:a003:49e7:478a:4675:2698) (Changing host)
- # [09:43] * Joins: mpt (~mpt@canonical/mpt)
- # [09:45] * Quits: jungkees (uid24208@gateway/web/irccloud.com/x-gibdnkvvwkixroky) (Quit: Connection closed for inactivity)
- # [09:47] * Joins: aleray (~aleray@ip-83-134-64-121.dsl.scarlet.be)
- # [09:47] * Quits: zcorpan (~zcorpan@c-5eeaaaa5-74736162.cust.telenor.se) (Remote host closed the connection)
- # [09:57] * Joins: darobin (~darobin@159.180.228.142)
- # [09:57] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [09:58] * Joins: zcorpan (~zcorpan@c-5eeaaaa5-74736162.cust.telenor.se)
- # [10:02] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
- # [10:13] * Joins: Ms2ger (~Ms2ger@60.219-242-81.adsl-dyn.isp.belgacom.be)
- # [10:17] * Quits: zcorpan (~zcorpan@c-5eeaaaa5-74736162.cust.telenor.se) (Remote host closed the connection)
- # [10:21] * Joins: g4 (~g4@unaffiliated/gormer)
- # [10:24] * Quits: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net) (Ping timeout: 244 seconds)
- # [10:25] * Quits: tripu (~tripu@2001:200:0:8805:4d2f:f601:ad6e:6d15) (Quit: Leaving)
- # [10:33] * Quits: kbx (~kbx@2401:fa00:4:1013:593c:ee82:21a9:bbf9) (Ping timeout: 272 seconds)
- # [10:34] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [10:38] * Quits: KevinMarks__ (~yaaic@2607:fb90:519:b69f:d68d:9798:a700:b0fd) (Ping timeout: 265 seconds)
- # [10:39] <JakeA> annevk: when is the right time to make response/request.body a ReadableStream in the fetch spec?
- # [10:43] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
- # [10:45] * Joins: kbx (~kbx@2401:fa00:4:1013:593c:ee82:21a9:bbf9)
- # [10:46] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [10:54] * Joins: wilsonpage (~wilsonpag@217.111.161.212)
- # [10:54] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
- # [10:58] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [11:03] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
- # [11:08] <annevk> JakeA: I was waiting for "tee" to be defined
- # [11:09] <annevk> JakeA: seems to be the only issue left: https://github.com/yutakahirano/fetch-with-streams/issues
- # [11:09] <JakeA> annevk: gotcha, cheers
- # [11:09] <annevk> JakeA: well, and also, I'm waiting for some confirmation that this design is okay
- # [11:10] <annevk> JakeA: I wish there was a second implementation
- # [11:13] * Joins: LJWatson (~chatzilla@cpc2-hawk13-2-0-cust240.aztw.cable.virginm.net)
- # [11:13] * Joins: espadrine (~tyl@LMontsouris-656-1-2-84.w80-12.abo.wanadoo.fr)
- # [11:16] <hsivonen> MikeSmith: If I tweak the TLS config for the validator, do you have a preference whether I should set properties procedurally in Main.java or via external files and command line switches managed by build.py?
- # [11:16] <hsivonen> I'm leaning towards Main.java, because the command line is pretty crazy already
- # [11:17] <MikeSmith> hsivonen: yeah, in Main.java sounds better to me as well
- # [11:17] <hsivonen> MikeSmith: OK. thanks
- # [11:17] <MikeSmith> hai
- # [11:29] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Remote host closed the connection)
- # [11:31] * Quits: LJWatson (~chatzilla@cpc2-hawk13-2-0-cust240.aztw.cable.virginm.net) (Quit: Carpe diem)
- # [11:31] * Joins: LJWatson (~chatzilla@cpc2-hawk13-2-0-cust240.aztw.cable.virginm.net)
- # [11:44] * Quits: jochen__ (jochen@nat/google/x-sllsholmclzzotfa) (Remote host closed the connection)
- # [11:50] * Quits: kbx (~kbx@2401:fa00:4:1013:593c:ee82:21a9:bbf9) (Ping timeout: 256 seconds)
- # [11:50] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
- # [11:59] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [11:59] * wilsonpage is now known as wilsonpage-away
- # [12:00] * Quits: wilsonpage-away (~wilsonpag@217.111.161.212) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # [12:01] * Joins: dshwang (dshwang@nat/intel/x-bsymojqxsksdcuss)
- # [12:03] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
- # [12:11] * Joins: wilsonpage (~wilsonpag@217.111.161.212)
- # [12:29] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (Ping timeout: 256 seconds)
- # [12:29] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
- # [12:30] <mounir> am I correct that per webidl, if I want a dictionary parameters with values depending on other parameters, i need to have a base dictionary in the method parameter type?
- # [12:32] * Quits: psy_ (~psy@103.6.159.177) (Ping timeout: 272 seconds)
- # [12:34] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Quit: Ex-Chat)
- # [12:36] <Ms2ger> What
- # [12:36] <mounir> Ms2ger: I have navigator.permissions.query(name, options)
- # [12:36] <mounir> options will depend on "name"
- # [12:37] <Ms2ger> You mean like canvas.getContext()?
- # [12:37] <Ms2ger> I thought we decided that wasn't a pattern we wanted to repeat
- # [12:39] <mounir> Ms2ger: except that "name" is part of an enum
- # [12:39] <mounir> and it's only used to know a permission state, not to get a feature
- # [12:53] * Quits: aleray (~aleray@ip-83-134-64-121.dsl.scarlet.be) (Ping timeout: 250 seconds)
- # [12:57] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 246 seconds)
- # [13:00] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [13:02] * Joins: zcorpan (~zcorpan@ip-200.t2.se.opera.com)
- # [13:08] * Joins: calvaris (~calvaris@fanzine.igalia.com)
- # [13:11] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [13:14] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
- # [13:14] * Joins: jungkees (uid24208@gateway/web/irccloud.com/x-tjwpvhrcghxehyzd)
- # [13:23] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [13:25] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 246 seconds)
- # [13:41] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-ibaviziqjkokzeew)
- # [13:59] * wilsonpage is now known as wilsonpage-away
- # [14:05] * Joins: aleray (~aleray@109.134.116.118)
- # [14:08] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Remote host closed the connection)
- # [14:10] <JakeA> Domenic: let me know when you're free to drown in the lands of cancellable promises
- # [14:12] * Joins: xiinotulp (~plutoniix@node-10d8.pool-180-180.dynamic.totbb.net)
- # [14:15] * Quits: plutoniix (~plutoniix@node-kzs.pool-101-108.dynamic.totbb.net) (Ping timeout: 248 seconds)
- # [14:17] * wilsonpage-away is now known as wilsonpage
- # [14:24] * Joins: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca)
- # [14:26] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Quit: Ex-Chat)
- # [14:32] * Joins: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net)
- # [14:36] * Quits: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net) (Remote host closed the connection)
- # [14:46] * Joins: newtron (~newtron@199.71.174.203)
- # [14:46] * wilsonpage is now known as wilsonpage-away
- # [14:47] * wilsonpage-away is now known as wilsonpage
- # [14:50] * Joins: scor (scor@drupal.org/user/52142/view)
- # [14:53] * Quits: wilsonpage (~wilsonpag@217.111.161.212) (Quit: Textual IRC Client: www.textualapp.com)
- # [14:53] <zcorpan> why is there no TouchEvent constructor?
- # [14:53] * Joins: wilsonpage (~wilsonpag@217.111.161.212)
- # [14:55] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
- # [14:55] * Joins: scor (scor@nat/acquia/x-sqirewaowbeqacps)
- # [14:55] * Quits: scor (scor@nat/acquia/x-sqirewaowbeqacps) (Changing host)
- # [14:55] * Joins: scor (scor@drupal.org/user/52142/view)
- # [14:59] <wilsonpage> roc ping
- # [15:02] * Quits: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca) (Remote host closed the connection)
- # [15:03] * Joins: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net)
- # [15:03] * Joins: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca)
- # [15:03] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-xyhitqlwjlgcebhz)
- # [15:04] <annevk> wanderview: hey, where are we at with https://github.com/yutakahirano/fetch-with-streams/issues/25 and streams in general?
- # [15:04] * xiinotulp is now known as plutoniix
- # [15:07] * Quits: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca) (Ping timeout: 250 seconds)
- # [15:14] * Joins: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca)
- # [15:15] * Joins: zenith_ (~zenith@199-7-157-3.eng.wind.ca)
- # [15:18] * Joins: zecho (~zecho@66-247-17-199.northern.mnscu.edu)
- # [15:21] * Quits: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca) (Remote host closed the connection)
- # [15:23] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Quit: Leaving)
- # [15:24] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [15:32] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Quit: Leaving)
- # [15:32] <annevk> zcorpan: do you know if Chromium has an origin associated with the global?
- # [15:32] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [15:34] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Client Quit)
- # [15:36] <zcorpan> annevk: don't know
- # [15:42] * Joins: mven (~textual@72.183.104.138)
- # [15:42] * Quits: mven (~textual@72.183.104.138) (Excess Flood)
- # [15:42] <wanderview> annevk: at this point I do not feel comfortable implementing that... I'm planning to talk to sicking in a couple weeks to try to iron out our differences
- # [15:45] <annevk> JakeA: given wanderview's statement and not hearing anything from Apple/Microsoft I'm inclined to hold off on integrating streams for now
- # [15:47] <JakeA> annevk: makes sense, wasn't aware of wanderview's concerns
- # [15:47] * Joins: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com)
- # [15:47] <wanderview> annevk: I guess to clarify, I'm personally ok with implementing the fetch body stream bit... but I need to address sicking's concerns first... and it feels like we're further away from agreement than I thought before
- # [15:49] <wanderview> JakeA: not my personal concerns... we need some internal consensus before moving forward, though
- # [15:49] <wanderview> if that makes sense
- # [15:49] * Joins: ehynds (~ehynds@64.206.121.41)
- # [15:51] * Joins: ^esc_ (~esc-ape@178.165.131.93.wireless.dyn.drei.com)
- # [15:53] * Quits: ^esc (~esc-ape@178.115.129.79.wireless.dyn.drei.com) (Ping timeout: 264 seconds)
- # [15:56] * Joins: TallTed (~Thud@63.119.36.36)
- # [16:01] * Joins: ehsan (~ehsan@2001:450:1f:224:89e6:c7e0:a161:5691)
- # [16:05] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
- # [16:18] * Joins: eric_carlson (~ericc@17.202.49.94)
- # [16:19] * Joins: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com)
- # [16:23] <jgraham> Anyone know of a version of something like jsfiddle or the live dom viewer with support for multiple origins?
- # [16:26] * Joins: psy_ (~psy@103.6.159.177)
- # [16:33] * Quits: sarri (~sari@unaffiliated/sarri) (Ping timeout: 265 seconds)
- # [16:34] * Joins: sarri (~sari@unaffiliated/sarri)
- # [16:36] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
- # [16:36] * Quits: zcorpan (~zcorpan@ip-200.t2.se.opera.com) (Remote host closed the connection)
- # [16:39] * Quits: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com) (Ping timeout: 256 seconds)
- # [16:42] * Quits: g4 (~g4@unaffiliated/gormer) (Quit: Leaving)
- # [16:44] * Joins: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net)
- # [16:45] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 265 seconds)
- # [16:45] * Joins: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com)
- # [16:47] * Quits: zenith_ (~zenith@199-7-157-3.eng.wind.ca) (Ping timeout: 245 seconds)
- # [16:52] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
- # [16:57] * Quits: zdobersek (~zan@46.166.188.215) (Ping timeout: 264 seconds)
- # [16:58] * Joins: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net)
- # [16:59] * Joins: zenith_ (~zenith@142.150.23.90)
- # [17:00] * Quits: LJWatson (~chatzilla@cpc2-hawk13-2-0-cust240.aztw.cable.virginm.net) (Quit: Carpe diem)
- # [17:06] * Quits: wilsonpage (~wilsonpag@217.111.161.212) (Quit: Textual IRC Client: www.textualapp.com)
- # [17:10] * Joins: eBureau (~Bruno@181.164.77.172)
- # [17:10] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [17:12] * Quits: eric_carlson (~ericc@17.202.49.94) (Quit: eric_carlson)
- # [17:13] * Quits: annevk (~annevk@77-57-114-240.dclient.hispeed.ch) (Ping timeout: 255 seconds)
- # [17:24] * Quits: darobin (~darobin@159.180.228.142) (Remote host closed the connection)
- # [17:28] <Domenic> JakeA: let's do this
- # [17:29] <Domenic> wow that thread really got overrun
- # [17:29] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Quit: Leaving)
- # [17:29] <JakeA> Domenic: yeah. Where's the best place to do this, here?
- # [17:29] <Domenic> seems reasonable
- # [17:30] <Domenic> Unless you want VC or something for higher bandwidth
- # [17:31] * Joins: jernoble (~jernoble@166.170.40.243)
- # [17:32] <JakeA> We'll try here and if that isn't good enough (or annoys people here) we'll go VC
- # [17:32] <JakeA> Will be back in a min
- # [17:33] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [17:35] <JakeA> Domenic: so, I get the feeling you've been around the ref-counting idea before, and every other cancellable-promise proposal, and you don't think it's possible outside of a token-based system. Is that true?
- # [17:37] <Domenic> JakeA: I think ref-counting is tricky business with lots of edge cases and potential usability hazards. I'd want to see it worked out in excruciating detail before saying it's workable.
- # [17:38] <Domenic> I'm also sympathetic to the argument that it's philosophically "wrong", i.e. cancellation should be a property of the operation and not of the result.
- # [17:38] <Domenic> JakeA: as an example I'd wonder if Promise.prototype.then.call(cancelablePromise, f, r) increases the ref count, or even works at all.
- # [17:40] * Joins: eric_carlson (~ericc@17.202.49.94)
- # [17:40] <JakeA> Domenic: I think it would increase ref count. I initially thought otherwise, that the parent should only count cancellable children, but I think all children is more consistent
- # [17:40] <Domenic> JakeA: OK, so this would involve modifying the spec for Promise to be aware of CancelablePromise?
- # [17:41] * Joins: annevk (~annevk@213.55.184.211)
- # [17:43] <JakeA> Domenic: does a promise have a link to its children? (eg, a way to iterative over the and look at their state?)
- # [17:44] <Domenic> JakeA: only before it gets fulfilled or rejected; after that it aggressively cuts off references in order to avoid memory "leaks".
- # [17:44] * Quits: psy_ (~psy@103.6.159.177) (Read error: Connection reset by peer)
- # [17:45] <JakeA> Domenic: that seems ok then, since a settled promise cannot cancel. Promise.prototype.then.call(cancelablePromise, f, r) would still create a cancellable promise
- # [17:46] <Domenic> Hmm OK, so @@species is still CancelablePromise
- # [17:46] * Quits: zenith_ (~zenith@142.150.23.90) (Ping timeout: 255 seconds)
- # [17:46] <JakeA> Promise.resolve(cancellablePromise) will create a child plain Promise
- # [17:46] <Domenic> right
- # [17:46] <Domenic> So you can't use this to just cancel a fetch operation then, if the headers have already been received
- # [17:46] <Domenic> You need to do the chaining thing
- # [17:47] <Domenic> But you can't e.g. create a token, do some fetches (which shar ethe token), then when people navigate the page, cancel the token and thus destroy all chained processing
- # [17:47] <Domenic> instead you have to keep track of all child promises
- # [17:47] <Domenic> and cancel them, when people navigate the page
- # [17:47] <Domenic> ("navigate the page" = within a single-page app, not browser navigation)
- # [17:47] <JakeA> fetch(url).then(r => r.json()) - both fetch() and r.json() are cancellable
- # [17:47] <Domenic> right, but
- # [17:48] <Domenic> compare with:
- # [17:48] * Joins: bradleymeck_ (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com)
- # [17:48] <Domenic> var canceller = new Canceller(); var p1 = fetch(url1, { canceller }); var p2 = fetch(url2, { canceler }); doStuffWith(p1, p2); doMoreStuffWith(p1, p2); /* later */ canceller.cancel();
- # [17:48] * Quits: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com) (Read error: Connection reset by peer)
- # [17:48] * bradleymeck_ is now known as bradleymeck
- # [17:49] * Joins: psy_ (~psy@103.6.159.177)
- # [17:49] <Domenic> tokens allow you, as the initiator of fetch, to decide when to stop
- # [17:49] <Domenic> instead of depending on your consumers to coordinate and say "oh, we'd better all cancel at the same time"
- # [17:50] <Domenic> I guess you could build that on top of promise.cancel() though
- # [17:50] <Domenic> well, but not for after-headers-have-arrived...
- # [17:50] <Domenic> unsure
- # [17:50] <JakeA> Domenic: var p1 = fetch(url); /* pass p1 to some other code which does whatever it wants */ p1.cancel(); /* kill the downward chain */
- # [17:51] <Domenic> right but you don't actually kill the downward chain because of ref-counting
- # [17:51] <Domenic> if "whatever it wants" includes a .then, you lose.
- # [17:52] <Domenic> I guess you could Promise.resolve() it first
- # [17:52] <Domenic> Can we turn things around for a bit? Why do you find the ref-counting solution more attractive? It seems less flexible and harder to reason about, to me.
- # [17:52] <JakeA> Domenic: ref-counting isn't used on the promise you call .cancel on, it stops straight away & cancels all children. Ref counting is used to decide if the parent should now be cancelled
- # [17:53] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
- # [17:53] <Domenic> JakeA: oh interesting... so cancel flows in both directions
- # [17:53] <Domenic> down like rejection, but also up to parents
- # [17:53] <JakeA> If you call p.cancel() this promise will always cancel as long as it hasn't settled, as will all its children and so on. p's parent may cancel, if p was its only child or all its children have cancelled
- # [17:53] <JakeA> That's what I was thinking
- # [17:53] <Domenic> huh
- # [17:54] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
- # [17:54] <Domenic> hmm ok back to the modifying-Promise-spec
- # [17:54] <Domenic> because there's no linkage from child to parent right now
- # [17:55] <Domenic> i guess it's only necessary for CancelablePromises
- # [17:55] <Domenic> I worry a bit about the implicit reference causing memory leaks
- # [17:55] <JakeA> Domenic: once the promise settles it can kill its parent link
- # [17:55] <JakeA> as it can no longer be cancelled
- # [17:55] <Domenic> var q = cancelablePromise.then(x).then(y).then(z).then(w) keeps 5 promises alive whereas for normal promises it'd be just 1
- # [17:56] <Domenic> hmm right ok so maybe it's the same then
- # [17:56] <Domenic> probably
- # [17:58] <JakeA> So when p.cancel() is called, it walks up the chain to find the highest promise that can be cancelled. That promise gets its cancel callback called, then the others get [rejected/hung/something else]
- # [17:58] <Domenic> the others?
- # [17:59] <JakeA> Sorry, down the chain from the one that gets cancelled
- # [17:59] <Domenic> right, ok
- # [17:59] <Domenic> so unwinding the stack a bit ... why do you like this design?
- # [18:01] <JakeA> Domenic: var p1 = fetch(url); var child1 = p1.then(r => consumeStream(r)); var child11 = child1.then(doSomethingElse); child11.cancel();
- # [18:02] <JakeA> Taking that example:
- # [18:03] <JakeA> If there's another p1.then(…), the child11 will appear cancelled, but the underlying fetch will not, so the branch is safe
- # [18:03] * Joins: iandevlin (~iandevlin@dslb-092-072-178-168.092.072.pools.vodafone-ip.de)
- # [18:03] <Domenic> yep, i got that
- # [18:04] <Domenic> not sure why you think it's a good experience though, in comparison to the initiator of the fetch being in control
- # [18:04] <JakeA> If there's no branch, then either the fetch or the stream read will be cancelled. If they've both finished, doSomethingElse will appear cancelled even if it carries on its work (because it returns a normal promise)
- # [18:04] <Domenic> what does "doSomethingElse will appear cancelled" mean?
- # [18:07] <JakeA> Domenic: its call to resolve/reject will not do anything, because the promise has been cancelled. What happens on promise cancel is still up for grabs, perhaps reject with undefined or an AbortError
- # [18:07] <Domenic> whose call to resolve/reject?! I thought doSomethingElse was just a function? Maybe write out its body...
- # [18:07] <JakeA> Sorry, yeah, that would be more helpful: .then(r => setTimeout(_ => r("Hello"), 1000))
- # [18:08] <JakeA> hang on
- # [18:08] <JakeA> that's wrong
- # [18:08] <Domenic> thta's... not how .then works...
- # [18:08] * Quits: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net) (Ping timeout: 256 seconds)
- # [18:08] <JakeA> yeah sorry, brain break
- # [18:08] <Domenic> np
- # [18:08] <JakeA> .then(_ => new Promise(r => setTimeout(_ => r("Hello"), 1000)))
- # [18:08] * Joins: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net)
- # [18:09] <JakeA> Basically, doSomethingElse resolves in 1 second with "Hello"
- # [18:10] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
- # [18:10] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Remote host closed the connection)
- # [18:10] <frivoal> Does anyone remember who was involved in thinking / making -o-double-rainbow() ?
- # [18:10] * JakeA thinks about the token solution some more
- # [18:11] <annevk> frivoal: I think I suggested that to whoever was implementing gradients at the time
- # [18:11] <Domenic> OK, so I think what you meant was "doSomethingElse isn't even called"
- # [18:12] <frivoal> annevk: thanks, I suspected you might be the one to thank for that.
- # [18:12] <JakeA> Domenic: if it's called, but the second hasn't passed, .cancel() would still "work" in that the promise won't resolve with "Hello"
- # [18:12] <JakeA> r("Hello") will be called, but since the promise is in a cancelled state (which could just mean rejected) it's ignored
- # [18:12] <Domenic> oh hmm that's weird
- # [18:13] <Domenic> so child11 is resolved already but you un-resolve it when you cancel
- # [18:13] <Domenic> or change its resolution or something
- # [18:13] <frivoal> annevk: Would I be wrong to attribute this work of art to Bruce Lawson: http://media.opera.com/media/press/2011/unicorn/ ?
- # [18:13] <Domenic> (child1 is pending-but-resolved in your example)
- # [18:13] <JakeA> Domenic: that doesn't sound right…
- # [18:14] <Domenic> JakeA: child11 is pending, since doSomethingElse returns a promise that is still pending-for-a-second. But it's resolved to that pending-for-a-second promise.
- # [18:14] * Joins: ap (~ap@17.202.44.214)
- # [18:14] <Domenic> normally that would mean it's locked in to follow that pending-for-a-second promise without fail.
- # [18:15] <annevk> frivoal: not sure
- # [18:15] * Joins: Maurice` (copyman@unaffiliated/maurice)
- # [18:15] <annevk> frivoal: was it Leif Arne who should get the credit?
- # [18:15] * annevk forgot :-(
- # [18:16] <frivoal> annevk: possibly
- # [18:16] <JakeA> Domenic: child11 is pending, calling .cancel() makes it (let's say) reject, the timeout hits, resolve is called, it's ignored
- # [18:17] * Quits: jernoble (~jernoble@166.170.40.243) (Quit: Computer has gone to sleep.)
- # [18:17] <Domenic> JakeA: let's break this down. `var p = new Promise(r => setTimeout(() => r("Hello"), 1000))`
- # [18:18] <Domenic> function doSomethingElse() { return p; }
- # [18:18] <Domenic> var child11 = child1.then(doSomethingElse)
- # [18:18] <Domenic> This immediately does PromiseResolve(child11, p)
- # [18:18] <wanderview> if we make fetch() return an extended promise with a fetch-specific cancel... can we later switch to a CancellablePromise once we see that it works out?
- # [18:18] <frivoal> annevk: Yep, it seems to be Leif Arne: https://twitter.com/rchl2k/status/135129843170947072
- # [18:18] <Domenic> You cannot reject a resolved promise
- # [18:19] <annevk> frivoal: nice find
- # [18:19] <Domenic> JakeA: similar example: var q = new Promise((res, rej) => res(p); rej(new Error("foo"))); q will be pending for 1 second then fulfilled with "Hello"
- # [18:20] <annevk> wanderview: that's the terminate() proposal, and yeah, I think there's agreement that can work, though there's still the open question there whether to do forever-pending or reject or allow for both
- # [18:21] <JakeA> Domenic: hmm, yeah, I see *thinks*
- # [18:21] * Joins: darobin (~darobin@mtl93-18-78-208-93-24.fbx.proxad.net)
- # [18:21] <wanderview> annevk: I guess the problem with that is it just breaks the Promise API niceness.. you can't really chain off the fetch() any more
- # [18:22] <annevk> wanderview: yup, though if you want to do complicated things you can't really chain anyway I think
- # [18:22] <Domenic> I'm still not sure keeping terminate-ability through a chain is desirable
- # [18:22] <Domenic> i kind of feel it should only belong to the initiator
- # [18:23] <Domenic> that's a key difference here I think
- # [18:23] <Domenic> I could be convinced otherwise but that's my conservative position
- # [18:23] <wanderview> annevk: I wonder if we could so something like fetch(req).control(function(controller) { .. }).then(function (response) { });
- # [18:23] <wanderview> and controller.cancel()
- # [18:24] <annevk> wanderview: why .control?
- # [18:24] * Quits: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net) (Remote host closed the connection)
- # [18:24] <wanderview> annevk: the idea being fetch() returns an extended promise with a .control()... letting you get a handle to the controller for later use... because the decision to cancel will be async most likely
- # [18:25] <annevk> Domenic: if there was an established API pattern that would be an easy sell
- # [18:25] <wanderview> and .control() returns a Promise for the response
- # [18:25] <annevk> wanderview: why not just make control an argument to fetch()?
- # [18:25] <wanderview> annevk: that works for me too
- # [18:25] * Joins: zcorpan (~zcorpan@2a00:801:e0:30:bd35:f8ae:6af2:99c2)
- # [18:26] <wanderview> pretty sure we've discussed this before... I think I just like that approach from a "how I would want to use it in code" point of view
- # [18:26] <wanderview> annevk: I guess .control() seems slightly nicer than a fetch arg because then it fits into the chaining pattern nicely
- # [18:26] * wanderview shrugs
- # [18:27] <annevk> fetch(url, control: c => c.abort()) just seems rather ugly
- # [18:27] <annevk> fetch(url).control(c => c.abort()) doesn't seem too different
- # [18:27] * Joins: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net)
- # [18:29] <wanderview> annevk: it would really be fetch(url).control(c => savedControl = c).then(response => ...);
- # [18:29] * Quits: encryptd_fractl (~encryptd_@c-98-240-134-35.hsd1.mn.comcast.net) (Remote host closed the connection)
- # [18:29] <Domenic> I still like `var c = new FetchController()`; fetch(url, { controller })` or similar.
- # [18:30] <wanderview> Domenic: thats nice
- # [18:30] <Domenic> the upside being you can hand out the same controller to multiple fetches
- # [18:30] * Quits: iandevlin (~iandevlin@dslb-092-072-178-168.092.072.pools.vodafone-ip.de) (Quit: Nettalk6 - www.ntalk.de)
- # [18:32] <wanderview> Domenic: yea... and if we make individual Promises cancellable... then the page has to rebuild a controller for themself by aggregating a promise for each fetch() in the place where the "cancel now" event happens
- # [18:33] * Joins: zenith_ (~zenith@142.150.23.90)
- # [18:33] <Domenic> wanderview: right, that was kind of my worry... although you could probably build a wrapper that implements either on top of the other
- # [18:33] * Quits: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [18:35] <wanderview> I just can't think of a use case where you want to stick .cancel() at the end of a Promise chain... and Promise chain syntax does not lend itself to getting a reference to the promise itself, except at the end of the chain
- # [18:36] * Quits: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com) (Read error: Connection reset by peer)
- # [18:36] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
- # [18:36] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
- # [18:36] <Domenic> Well, I dunno, it's fairly believable for non-branching chains
- # [18:36] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
- # [18:37] * Joins: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com)
- # [18:37] <JakeA> wanderview: fetch(url).then(r => r.json())
- # [18:38] <Domenic> var result = fetch(url).then(r => r.json()).then(parseJSONIntoModel).then(updateUI); router.on("hashchange", () => result.cancel())
- # [18:38] <JakeA> right
- # [18:38] <Domenic> not much different from `var canceller = new Canceller(); fetch(url, { canceller }).then(...).then(...).then(...); router.on("hashchange", () => canceller.cancel())` admittedly.
- # [18:39] <wanderview> ok
- # [18:39] <Domenic> but less work if the router.on(...) code is located somewhere else; becomes an issue of passing it a { promise, canceller } pair vs. a promise by itself
- # [18:39] <Domenic> unsure though, this example is kind of unrealistic
- # [18:39] <wanderview> Domenic: I guess the Canceller example is more clear it only effects fetch()... the first example suggests you can cancel parseJSONIntoModel, etc
- # [18:40] <Domenic> wanderview: ah yeah hmm i guess that's actually a downside though...
- # [18:40] <JakeA> Domenic: so, going back to what you said earlier, var p = fetch(url).then(r => r.json()) - calling .cancel() wouldn't work if we had headers, since the .then is immediately resolved with the r.json() promise.
- # [18:40] * Joins: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek)
- # [18:40] <wanderview> Domenic: downside for the controller approach? how so?
- # [18:40] <Domenic> that's a pretty bad downside really
- # [18:41] <Domenic> wanderview: because you want an easy way to stop parsing or updating the UI too
- # [18:41] <wanderview> Domenic: they may not be cancellable, though... for example if the parse is synchronous (which is probably is)
- # [18:42] <Domenic> wanderview: so it becomes fetch(url, { canceller }).then(r => r.json({ canceller })).then(j => parseJSONIntoModel(j, { canceller })).then(m => updateUI(m, { canceller }))
- # [18:42] <Domenic> wanderview: yeah true
- # [18:43] * Joins: bholley (~bholley@c-24-130-121-49.hsd1.ca.comcast.net)
- # [18:43] <Domenic> JakeA: hmm yes that's true -_-
- # [18:43] * Joins: jwalden (~waldo@c-68-60-39-249.hsd1.mi.comcast.net)
- # [18:44] <JakeA> Domenic: So the resolved value needs to be treated as a chain too
- # [18:44] <wanderview> Domenic: if you want a cancellable parse, use a Stream? :-)
- # [18:44] <Domenic> wanderview: haha true.
- # [18:44] * Joins: encryptd_fractl (~encryptd_@204.73.55.132)
- # [18:44] <Domenic> JakeA: not sure what the implications of that are.
- # [18:45] <JakeA> Domenic: me neither
- # [18:45] <JakeA> I feel we're getting closer to fetch() returning a FetchPromise with an abort() methods with a @@species of Promise
- # [18:46] <Domenic> the terminate() solution, you mean?
- # [18:46] <JakeA> yeah, terminate()
- # [18:46] <Domenic> why is that better than canceller?
- # [18:47] <JakeA> Canceller seems ugly to me, maybe I'll get used to it
- # [18:47] <Domenic> the weight of minting a new promise subclass, especially one of such limited use, makes me hesitant.
- # [18:47] <JakeA> I'll probably get used to it
- # [18:47] <Domenic> if we had more methods to put on it then i'd feel better
- # [18:47] <Domenic> e.g. http2 priority-adjuster?
- # [18:48] <wanderview> how do cancel response.json?
- # [18:48] <wanderview> response.body.cancel(), doesn't work right?
- # [18:48] <wanderview> Domenic: JakeA: ^^^
- # [18:48] <JakeA> wanderview: it would have to take a canceller or similar
- # [18:49] <Domenic> yeah, that
- # [18:49] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
- # [18:49] <wanderview> JakeA: or have response.cancel()
- # [18:49] <Domenic> do we really want to give that authority to anyone though?
- # [18:50] <wanderview> Domenic: how does one get a handle to the same Response object without being the same code that sets up the cancel?
- # [18:50] * Quits: bholley (~bholley@c-24-130-121-49.hsd1.ca.comcast.net) (Quit: ZZZzzz…)
- # [18:50] <Domenic> i dunno the ergonomics argument is making me want to reconsider JakeA's ideas... if we can make them work somehow...
- # [18:50] <Domenic> wanderview: doSomethingWith(response) :)
- # [18:50] <Domenic> wanderview: it's a matter of, when you give someone a response, are you also giving them ability to blow up the response? or just to read it (if it's not locked)?
- # [18:51] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
- # [18:51] <Domenic> i think we made res.headers immutable for similar reasons?
- # [18:51] <wanderview> Domenic: if you don't trust the code you can call doSomethingWith(response.clone())
- # [18:52] <Domenic> wanderview: true true.
- # [18:52] <wanderview> Domenic: because they could drain the body and "blow up" the Response as well
- # [18:52] <Domenic> wanderview: not if it's locked though.
- # [18:52] <wanderview> Domenic: I find the lock blocking cancel very unexpected, to be honest
- # [18:53] <JakeA> Domenic: https://github.com/slightlyoff/ServiceWorker/issues/592#issuecomment-68853209 - here I say "If the user hits X (or even closes the tab) while /whatever.json is fetching, I don't think we can simply cancel the request", this is because the tab isn't consuming the stream at this point. With a chaining cancellable promise, this is no longer an issue
- # [18:53] <Domenic> :-S
- # [18:53] <JakeA> This is a case where you want the party you give the promise to to be able to cancel, rather than the initiator
- # [18:53] <wanderview> Domenic: simultaneous reads is good to block with a lock... but having some async thing cancel a stream while another bit of code is reading seems pretty commonplace to me
- # [18:53] <Domenic> JakeA: is "we" the browser or author code in that sentence?
- # [18:54] <JakeA> Domenic: the browser
- # [18:54] <Domenic> wanderview: this is kind of just a principle of least authority thing I think
- # [18:54] <Domenic> JakeA: I think the stream becomes errored if it's prematurely terminated.
- # [18:54] <annevk> Domenic: we'd use a promise-subclass for other things too
- # [18:54] <annevk> Domenic: e.g. postMessage() with the SW
- # [18:54] <wanderview> Domenic: this forces Response.json(canceller) as the only solution then
- # [18:54] <annevk> Domenic: or changing priority of the fetch
- # [18:55] <wanderview> which is fine I guess
- # [18:55] <Domenic> wanderview: right, or a CancelablePromise solution that I've been arguing is complicated.
- # [18:55] * Joins: LJWatson (~chatzilla@cpc2-hawk13-2-0-cust240.aztw.cable.virginm.net)
- # [18:55] <wanderview> I guess, keep in mind that everything with the body stream effects Cache produced Responses as well... but canceling "before the headers" is fetch only
- # [18:56] <wanderview> unless Cache grows something similar to fetch
- # [18:56] * Quits: igoroliveira (uid20755@gateway/web/irccloud.com/x-ibaviziqjkokzeew) (Quit: Connection closed for inactivity)
- # [18:56] * wanderview doesn't want to allow canceling Cache.match(), etc.
- # [18:56] <annevk> Domenic: the only reason headers is immutable at the moment is because that's the easiest
- # [18:56] <annevk> Domenic: but we'll make it mutable together with request's headers
- # [18:56] * Joins: scor (scor@nat/acquia/x-szbilmafvouilvkw)
- # [18:56] * Quits: scor (scor@nat/acquia/x-szbilmafvouilvkw) (Changing host)
- # [18:56] * Joins: scor (scor@drupal.org/user/52142/view)
- # [18:56] <Domenic> annevk: hmm ok
- # [18:56] <annevk> Domenic: just needs some careful consideration of all the implications
- # [18:57] <wanderview> I wonder how much pain here is due to separating "we have headers" event from the body stream its parsed from
- # [18:57] <wanderview> ^body stream^data stream
- # [18:57] <Domenic> JakeA: now I'm curious if you can make CancelablePromise work generally. I think you need: 1) compelling ergonomics examples vs. canceller; 2) work through the semantics and edge cases in detail.
- # [18:58] <Domenic> JakeA: I can try to help with 2)...
- # [18:58] <annevk> wanderview: having headers also means no more redirects, it's a rather important milestone
- # [18:58] <wanderview> annevk: yes... but treating them as separate cancelable things when really there is one underlying stream supplying both
- # [18:58] <annevk> Domenic: I think the case for CancelablePromise is indeed primarily ergonomics
- # [18:58] <Domenic> wanderview: annevk: yeah, the have-headers milestone being separable is quite nice in practice, I think. Certainly can be a leaky abstraction in some cases though.
- # [18:59] <annevk> Domenic: having to construct a controller is awkward
- # [18:59] <Domenic> annevk: to me that's not the awkward part, the awkward part is lack of propagation
- # [18:59] <annevk> Domenic: when would it be a leaky abstraction?
- # [18:59] <annevk> Domenic: this is exactly as atomic as implementations are
- # [19:00] <Domenic> annevk: well it's leaky here because an implementation could cancel the underlying TCP stream at any point, but here we have this two-stage thing => potentially two cancel mechanisms
- # [19:01] <Domenic> lunchtime...
- # [19:01] <wanderview> I guess it does fit Cache better.... load meta-data separate from body data stream
- # [19:03] <JakeA> Domenic: I'll do as much of 1 as I can tomorrow
- # [19:05] * Joins: bholley (~bholley@c-24-130-121-49.hsd1.ca.comcast.net)
- # [19:05] * Quits: aleray (~aleray@109.134.116.118) (Ping timeout: 244 seconds)
- # [19:05] * Joins: jernoble (~jernoble@17.202.49.155)
- # [19:05] * Joins: zenith__ (~zenith@142.150.23.90)
- # [19:08] * Quits: zenith_ (~zenith@142.150.23.90) (Ping timeout: 272 seconds)
- # [19:08] * Joins: wilsonpage (~wilsonpag@217.111.161.212)
- # [19:13] * Joins: dbaron (~dbaron@2620:101:80fb:224:6120:58ca:192e:4635)
- # [19:16] * Quits: darobin (~darobin@mtl93-18-78-208-93-24.fbx.proxad.net) (Remote host closed the connection)
- # [19:16] * Quits: dshwang (dshwang@nat/intel/x-bsymojqxsksdcuss) (Remote host closed the connection)
- # [19:17] * Joins: dshwang (~dshwang@134.134.137.73)
- # [19:18] * Joins: aleray (~aleray@ip-83-101-52-107.customer.schedom-europe.net)
- # [19:24] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
- # [19:26] * Quits: LJWatson (~chatzilla@cpc2-hawk13-2-0-cust240.aztw.cable.virginm.net) (Quit: Carpe diem)
- # [19:28] * Joins: scor (scor@drupal.org/user/52142/view)
- # [19:28] * Joins: robogoat (~robogoat@c-24-126-240-124.hsd1.ga.comcast.net)
- # [19:29] * Quits: halfline (rstrode@nat/redhat/x-clvncclfpektkpjh) (Quit: ZNC - http://znc.in)
- # [19:29] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
- # [19:29] * Joins: halfline (rstrode@nat/redhat/x-heatlytmgxruejte)
- # [19:29] * Quits: zenith__ (~zenith@142.150.23.90) (Ping timeout: 256 seconds)
- # [19:30] * Quits: halfline (rstrode@nat/redhat/x-heatlytmgxruejte) (Remote host closed the connection)
- # [19:32] * Quits: espadrine (~tyl@LMontsouris-656-1-2-84.w80-12.abo.wanadoo.fr) (Ping timeout: 265 seconds)
- # [19:33] * Joins: halfline (rstrode@nat/redhat/x-uyofxhuwhqyzrbee)
- # [19:37] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
- # [19:38] * Quits: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com) (Read error: Connection reset by peer)
- # [19:38] * Joins: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com)
- # [19:39] * Joins: benwerd (~benwerd@199.87.84.238)
- # [19:40] * Quits: jernoble (~jernoble@17.202.49.155) (Quit: Textual IRC Client: www.textualapp.com)
- # [19:40] <JakeA> Domenic: has there been any further discussion on window.onerror alternatives for promises? onpromiseerror and onpromiseerrorhandled perhaps?
- # [19:41] <JakeA> Where the former would fire if a promise rejects without a reject handler, and the latter fires if it's later handled
- # [19:43] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Ping timeout: 272 seconds)
- # [19:43] <JakeA> wanderview: ohh, how are you cancelling those fetching in Gecko (from the promises thread)
- # [19:45] <wanderview> JakeA: all network requests in gecko have an associated "LoadGroup"... right now we call LoadGroup.cancel() when the ServiceWorker is shutdown
- # [19:45] <Domenic> JakeA: people liked it, nobody said "yeah let's implement it"
- # [19:45] <wanderview> JakeA: non-SW cases share the LoadGroup with the document and the LoadGroup.cancel() is triggered by navigation, etc
- # [19:45] <wanderview> JakeA: we also have a way of cancelling things when the worker thread is shutting down
- # [19:45] <JakeA> wanderview: ahh yeah, but that doesn't work if the SW stays alive, eg if the page is navigated within scope it's likely to stay alive
- # [19:45] <wanderview> JakeA: its poorly defined in the spec, I think :-(
- # [19:46] <wanderview> JakeA: for example... does the SW stay alive until respondWith() resolves a Response?
- # [19:46] <wanderview> or until the underlying Response body completes?
- # [19:46] <wanderview> what if there is an outstanding Cache.put() in operation? do we cancel that?
- # [19:46] <JakeA> wanderview: receives a response should be enough. We may need a fetchEvent.waitUntil for further tasks
- # [19:46] <JakeA> yeah, exactly
- # [19:47] <wanderview> JakeA: right... I think we may actually have to keep the worker thread alive until body is fully copied in... but that could just be our implementation
- # [19:47] <wanderview> right now we don't explicitly do that... probably a bug
- # [19:48] <wanderview> JakeA: I guess my point, though... is the browser can cancel this stuff regardless of what script does (without script using something like waitUntil() )
- # [19:48] <JakeA> wanderview: welllll it's not really a bug. The browser is allowed to keep the SW alive as long as it wants
- # [19:49] <JakeA> wanderview: those requests can only be cancelled if the promise has resolved, or if the browser can shut the SW down
- # [19:49] <wanderview> JakeA: I think we may stop the SW too soon in gecko right now
- # [19:50] <wanderview> JakeA: I haven't looked, but if navigation caused the FetchEvent to no longer be valid... we should be able to stop the SW and cancel those operations
- # [19:50] <wanderview> FetchEvent holds SW alive... Document should hold FetchEvent
- # [19:50] <wanderview> I'd have to check, though
- # [19:50] <JakeA> wanderview: but if the navigation is to another page in scope, the SW needs to be alive for that new page and its resources
- # [19:50] * Joins: jernoble (~jernoble@17.202.46.221)
- # [19:51] <wanderview> JakeA: true... these mechanisms will not cancel in that case
- # [19:51] <JakeA> wanderview: maybe an edge case though
- # [19:52] <wanderview> JakeA: canceling per FetchEvent seems reasonable... if the FetchEvent is going nowhere
- # [19:52] <JakeA> wanderview: will design fetchEvent.waitUntil tomorrow
- # [19:52] <wanderview> JakeA: I suppose the FetchEvent could be for a window.fetch() that gets canceled too :-)
- # [19:53] <wanderview> FetchEvent cancellation I mean
- # [19:53] <JakeA> haha
- # [19:56] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
- # [19:56] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
- # [19:57] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
- # [19:59] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [20:01] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
- # [20:01] * Joins: benwerd (~benwerd@199.87.84.238)
- # [20:02] * Quits: benwerd (~benwerd@199.87.84.238) (Read error: Connection reset by peer)
- # [20:02] * Joins: benwerd_ (~benwerd@199.87.84.238)
- # [20:03] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
- # [20:09] * Joins: mbrubeck (sid17036@gateway/web/irccloud.com/x-xhiubksdrvfaykwk)
- # [20:10] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
- # [20:12] * Quits: aleray (~aleray@ip-83-101-52-107.customer.schedom-europe.net) (Ping timeout: 246 seconds)
- # [20:13] * Krinkle|detached is now known as Krinkle
- # [20:14] * Quits: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com) (Quit: bradleymeck)
- # [20:15] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
- # [20:16] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
- # [20:17] * Quits: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net) (Quit: This computer has gone to sleep)
- # [20:19] * Parts: mbrubeck (sid17036@gateway/web/irccloud.com/x-xhiubksdrvfaykwk)
- # [20:22] * Joins: jernoble_ (~jernoble@17.202.49.155)
- # [20:23] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
- # [20:24] * Joins: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net)
- # [20:24] * Quits: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net) (Client Quit)
- # [20:25] * Joins: zenith_ (~zenith@142.150.23.90)
- # [20:25] * Quits: ehynds (~ehynds@64.206.121.41) (Read error: Connection reset by peer)
- # [20:32] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
- # [20:34] * Joins: bnicholson (~bnicholso@corp.mtv2.mozilla.com)
- # [20:37] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Remote host closed the connection)
- # [20:40] * Joins: bradleymeck (~bradleyme@70.114.246.88)
- # [20:43] * Quits: benwerd_ (~benwerd@199.87.84.238) (Remote host closed the connection)
- # [20:47] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [20:51] * Joins: benwerd (~benwerd@199.87.84.238)
- # [20:51] * Quits: bradleymeck (~bradleyme@70.114.246.88) (Read error: Connection reset by peer)
- # [20:52] * Joins: bradleymeck (~bradleyme@70.114.246.88)
- # [20:52] * Quits: encryptd_fractl (~encryptd_@204.73.55.132) (Remote host closed the connection)
- # [20:57] * Joins: darobin (~darobin@mtl93-18-78-208-93-24.fbx.proxad.net)
- # [21:00] * Quits: zecho (~zecho@66-247-17-199.northern.mnscu.edu) (Read error: Connection reset by peer)
- # [21:00] * Joins: zecho (~zecho@66-247-17-199.northern.mnscu.edu)
- # [21:02] * Joins: encryptd_fractl (~encryptd_@50.241.63.92)
- # [21:03] * Quits: encryptd_fractl (~encryptd_@50.241.63.92) (Read error: Connection reset by peer)
- # [21:04] * Joins: encryptd_fractl (~encryptd_@50.241.63.92)
- # [21:05] * Joins: marcosc (~marcosc@2001:450:1f:232:2d27:3fd4:617:9543)
- # [21:06] <mounir> Domenic: ping
- # [21:07] * Quits: bradleymeck (~bradleyme@70.114.246.88) (Read error: Connection reset by peer)
- # [21:07] <mounir> marcosc: ping
- # [21:07] <Domenic> pong
- # [21:08] * marcosc here
- # [21:08] * Joins: bradleymeck (~bradleyme@70.114.246.88)
- # [21:08] <mounir> marcosc: Domenic suggests to remove the base interface
- # [21:08] <mounir> or maybe use "implements"
- # [21:08] <mounir> I don't mind both, FWIW
- # [21:09] <Domenic> https://gist.github.com/domenic/db44ae9dd73534d63e46
- # [21:09] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
- # [21:09] <mounir> my main concern now is to figure out which way to go: strong types or strings
- # [21:09] <wanderview> JakeA: can we just remove VARY headers completely and make Cache key-value? :-)
- # [21:10] <Domenic> mounir: I think hanging methods off of types (instead of having a string-param to a generic method) is OK; not much preference either way. But, a strong preference *against* passing those types around.
- # [21:10] <mounir> Domenic: then we should try to see how we could add a .request() on top of that
- # [21:11] <mounir> Domenic: I want the design to allow .request() to take multiple permissions
- # [21:11] <mounir> the string based solution would allow that fairly easily
- # [21:11] <Domenic> yeah. .request(["midi", "geolocation"]), etc. seems fine. They are keys into Permissions.prototype.
- # [21:12] * Joins: othermaciej (~mjs@17.202.48.222)
- # [21:13] <mounir> Domenic: except that you would need to pass some options
- # [21:13] <marcosc> sorry, was chatting to other people at moz about the API at the same time
- # [21:13] <Domenic> Oh, interesting
- # [21:13] <Domenic> I suppose you guys have already explored and rejected coalescing separate requests?
- # [21:14] <Domenic> So e.g. the natural Promise.all([n.p.midi.request({ sysex: true }), n.p.geolocation.request()]) is not good enough?
- # [21:14] <marcosc> that's what we would want, yes
- # [21:15] <Domenic> oh, then, seems good...
- # [21:16] <marcosc> I don't have a strong preference about the strings vs the attributes
- # [21:16] <mounir> for .request(), I'm not sure Promise.all() is the right solution
- # [21:16] <Domenic> People will do it, even if you don't think they should
- # [21:17] <marcosc> you can handle individual rejects as needed, so what's the problem?
- # [21:17] <marcosc> "Oh, without Camera you are going to have a bad time... but ok..."
- # [21:17] * Quits: bholley (~bholley@c-24-130-121-49.hsd1.ca.comcast.net)
- # [21:18] <mounir> or UI coallescing, it's better if it's clear that the permission requests have to be bundled
- # [21:18] <mounir> instead of guessing
- # [21:24] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [21:24] * Quits: zcorpan (~zcorpan@2a00:801:e0:30:bd35:f8ae:6af2:99c2) (Remote host closed the connection)
- # [21:25] * Joins: zcorpan (~zcorpan@2a00:801:e0:30:bd35:f8ae:6af2:99c2)
- # [21:27] <mounir> Domenic: the more I think about it, the more I prefer the original design with only a dictionary passed to .query()
- # [21:28] <mounir> no name + options
- # [21:28] <Domenic> oh interesting
- # [21:28] <mounir> Domenic: a permission isn't defined by it's name but by the name and the options even if some doesn't
- # [21:28] <Domenic> hmmmm that makes sense
- # [21:29] <mounir> Domenic: you can't query() 'midi' or 'push', it's more a side effect that some options will have a default value
- # [21:30] <mounir> Domenic: how terrible is navigator.permissions.query({'name': 'foo'}); to you?
- # [21:30] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-ctjblkrenyqnrspm)
- # [21:30] <mounir> knowing that sometimes there would be other values?
- # [21:30] <Domenic> mounir: not so bad now that you explain the conceptual backing
- # [21:31] <Domenic> i wonder if it's coherent to have an overload that takes a string and converts it to { name: s } though
- # [21:31] <Domenic> Just for pure convenience
- # [21:31] <mounir> Domenic: that's exactly what I had, but slightlyoff hated it
- # [21:31] <Domenic> -_-
- # [21:32] <mounir> ;)
- # [21:32] <Domenic> { name: 'foo' } it is then!
- # [21:32] <zcorpan> MikeSmith: fwiw, w3c ip block issue turned out to be quite the mystery. something was hammering the svg blog, but we couldn't identify what. now it doesn't happen anymore. issue closed, mystery prevails
- # [21:37] * Joins: jsbell (jsbell@nat/google/x-naweydyblgxljubr)
- # [21:48] <darobin> zcorpan: that happened at my office, we tracked it down to someone having a misbehaved Chrome extension that kept hitting a bunch of W3C pages for no reason
- # [21:51] <Domenic> probably dtds
- # [22:01] <darobin> Domenic: nope, it was weirder
- # [22:01] * Quits: wilsonpage (~wilsonpag@217.111.161.212) (Quit: Textual IRC Client: www.textualapp.com)
- # [22:02] <darobin> I *think* that it was somehow trying to refresh an RSS feed that it autodetected from a page but getting it very wrong
- # [22:03] <zcorpan> the url here involved something about rss in the query string (but it didn't point to the svg blog's feed). also the request had no User-Agent.
- # [22:03] * Joins: wilsonpage (~wilsonpag@217.111.161.213)
- # [22:03] <zcorpan> know which extension?
- # [22:05] * Quits: encryptd_fractl (~encryptd_@50.241.63.92) (Ping timeout: 255 seconds)
- # [22:07] * Joins: zecho_ (~zecho@66-247-17-199.northern.mnscu.edu)
- # [22:07] * Quits: bradleymeck (~bradleyme@70.114.246.88) (Read error: Connection reset by peer)
- # [22:09] * Quits: zecho (~zecho@66-247-17-199.northern.mnscu.edu) (Ping timeout: 252 seconds)
- # [22:10] * Quits: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek) (Quit: Leaving.)
- # [22:12] * Joins: bradleymeck (~bradleyme@70.114.246.88)
- # [22:12] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
- # [22:13] * Joins: encryptd_fractl (~encryptd_@50.241.63.92)
- # [22:16] * Krinkle is now known as Krinkle|detached
- # [22:22] * Quits: bradleymeck (~bradleyme@70.114.246.88) (Quit: bradleymeck)
- # [22:23] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
- # [22:23] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
- # [22:26] * Joins: bradleymeck (~bradleyme@70.114.246.88)
- # [22:27] * Joins: espadrine (~tyl@dan75-7-88-166-187-54.fbx.proxad.net)
- # [22:33] * Quits: marcosc (~marcosc@2001:450:1f:232:2d27:3fd4:617:9543) (Remote host closed the connection)
- # [22:35] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
- # [22:36] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
- # [22:37] * Krinkle|detached is now known as Krinkle
- # [22:39] * Joins: jyasskin (jyasskin@nat/google/x-hppontpcgxmdztsm)
- # [22:39] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
- # [22:40] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 244 seconds)
- # [22:40] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
- # [22:48] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 265 seconds)
- # [22:49] * Joins: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com)
- # [22:49] * Quits: newtron (~newtron@199.71.174.203) (Ping timeout: 252 seconds)
- # [22:49] <[swift]> does anyone have an opinion on delivering visibilitychange events to iframes when they enter and exit the viewport?
- # [22:49] <[swift]> ack, znc keeps changing my nick
- # [22:50] * [swift] is now known as seth__
- # [22:50] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [22:50] * seth__ is now known as sethf
- # [22:50] <sethf> (or perhaps nickserv)
- # [22:51] <sethf> at any rate, the idea here would be to allow iframes to take actions to throttle themselves if they're not currently visible. think for example HTML5 ads - they may be performing a variety of kinds of work when visible that they may want to throttle down when the user has scrolled them off the page
- # [22:51] * Quits: zenith_ (~zenith@142.150.23.90) (Ping timeout: 272 seconds)
- # [22:52] * Joins: tschneidereit (~till@2620:101:80fb:224:3559:b40e:9348:f691)
- # [22:59] <zcorpan> sethf: seems like it could be useful. send a mail to the list?
- # [23:03] <sethf> zcorpan: that was step two =)
- # [23:03] <jamesr___> it's definitely come up
- # [23:03] * Quits: wilsonpage (~wilsonpag@217.111.161.213) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # [23:04] * Joins: aleray (~aleray@91.182.102.197)
- # [23:04] <sethf> jamesr___: i looked around for previous discussions but didn't have much luck finding any
- # [23:05] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
- # [23:05] <sethf> i may well be using the wrong keywords to search, though
- # [23:05] * Joins: ap_ (~ap@17.114.216.168)
- # [23:07] * Quits: CvP (~CvP@203.76.123.238) (Quit: [ UPP ] > all)
- # [23:08] * Quits: ap (~ap@17.202.44.214) (Ping timeout: 244 seconds)
- # [23:08] * Quits: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com) (Quit: tantek)
- # [23:08] * Joins: CvP (~CvP@203.76.123.238)
- # [23:11] * Quits: ap_ (~ap@17.114.216.168)
- # [23:12] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
- # [23:12] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
- # [23:12] * Quits: TallTed (~Thud@63.119.36.36)
- # [23:13] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
- # [23:14] * Joins: benwerd (~benwerd@199.87.84.238)
- # [23:15] * Quits: hober (~ted@unaffiliated/hober) (Read error: Connection reset by peer)
- # [23:15] * Joins: hober (~ted@unaffiliated/hober)
- # [23:16] * Quits: encryptd_fractl (~encryptd_@50.241.63.92) (Ping timeout: 252 seconds)
- # [23:17] * Joins: encryptd_fractl (~encryptd_@50.241.63.92)
- # [23:22] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
- # [23:22] * Quits: ehsan (~ehsan@2001:450:1f:224:89e6:c7e0:a161:5691) (Remote host closed the connection)
- # [23:27] <Ms2ger> Someone killed irc.w3.org?
- # [23:27] <gsnedders> So it appears. It wasn't me, though, honest!
- # [23:29] * Joins: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com)
- # [23:31] * jgraham blames gsnedders
- # [23:31] <gsnedders> Nah, I'm way too busy cursing SCSS to care.
- # [23:33] <jgraham> Should have called it CUSS
- # [23:33] * Joins: newtron (~newtron@75-119-235-26.dsl.teksavvy.com)
- # [23:33] * Joins: rniwa (~rniwa@17.202.48.231)
- # [23:34] <jgraham> Did I already spam this channel with https://docs.google.com/document/d/1K-mKOqiUiSjgZTEscBLjtjd6E67oiK8H2ztOiq5tigk/pub ?
- # [23:34] <jgraham> A most interesting look at web perf problems
- # [23:34] * Joins: marcosc (~marcosc@2001:450:1f:232:2d27:3fd4:617:9543)
- # [23:35] * Quits: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com) (Quit: tantek)
- # [23:36] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
- # [23:36] * Quits: Maurice` (copyman@unaffiliated/maurice)
- # [23:37] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [23:37] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
- # [23:38] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [23:39] * Quits: marcosc (~marcosc@2001:450:1f:232:2d27:3fd4:617:9543) (Ping timeout: 256 seconds)
- # [23:39] <gsnedders> tl;dr: JS makes everything slow?
- # [23:39] * Quits: newtron (~newtron@75-119-235-26.dsl.teksavvy.com) (Quit: Leaving...)
- # [23:39] * Joins: newtron (~newtron@75-119-235-26.dsl.teksavvy.com)
- # [23:39] * Quits: newtron (~newtron@75-119-235-26.dsl.teksavvy.com) (Client Quit)
- # [23:40] * Quits: encryptd_fractl (~encryptd_@50.241.63.92) (Remote host closed the connection)
- # [23:40] * Joins: encryptd_fractl (~encryptd_@50.241.63.92)
- # [23:40] * Quits: encryptd_fractl (~encryptd_@50.241.63.92) (Remote host closed the connection)
- # [23:41] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 272 seconds)
- # [23:42] * Joins: weinig (~weinig@17.244.160.62)
- # [23:45] * Quits: zcorpan (~zcorpan@2a00:801:e0:30:bd35:f8ae:6af2:99c2) (Remote host closed the connection)
- # [23:45] * Joins: benwerd (~benwerd@199.87.84.238)
- # [23:45] * Joins: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com)
- # [23:46] * Quits: bradleymeck (~bradleyme@70.114.246.88) (Quit: bradleymeck)
- # [23:46] * Joins: benwerd_ (~benwerd@199.87.84.238)
- # [23:46] * Quits: benwerd (~benwerd@199.87.84.238) (Read error: Connection reset by peer)
- # [23:47] * heycam|away is now known as heycam
- # [23:48] * Joins: ap_ (~ap@17.114.216.168)
- # [23:49] * Quits: benwerd_ (~benwerd@199.87.84.238) (Read error: Connection reset by peer)
- # [23:49] * Joins: benwerd (~benwerd@199.87.84.238)
- # [23:51] <jgraham> gsnedders: tldr for web authors is "if you want good perf you have to be super-careful about the code you actually run, rather than carelessly slinging about high level abstractions"
- # [23:51] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
- # [23:51] <darobin> jgraham: wow, great doc
- # [23:51] <jgraham> But there are also messages for platform engineers and people working on tools
- # [23:51] <darobin> I'd say tl;dr is "ads will kill your perf"
- # [23:51] <jgraham> Well that was certainly the most egregious thing
- # [23:52] <darobin> "a loading spinner, that’s a canvas element, is rotated with css transforms every 42ms, via setInterval."
- # [23:52] * Joins: ambv (~ambv@199.201.64.131)
- # [23:52] <darobin> that's, like, wat?
- # [23:52] <gsnedders> hey gifs are so 90s
- # [23:52] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
- # [23:52] <gsnedders> LIKE THIS GIF IF YOU'RE A 90S KID
- # [23:53] <jgraham> I was particularly horrified by the adsense script running in a scroll handler and taking 25ms
- # [23:53] <darobin> gsnedders: sure, I mean, why not. but do you need to replace the gif by using setInterval to animate a CSS transform that CSS could animate itself, to rotate a fucking canvas that could rotate itself?
- # [23:53] <tantek> lol adsense. NoScript. block adsense everywhere.
- # [23:53] * Quits: roc (~chatzilla@121-98-104-251.bng1.tvc.orcon.net.nz) (Remote host closed the connection)
- # [23:53] <darobin> tantek: this is for performance for real users
- # [23:53] <gsnedders> darobin: yes
- # [23:54] <tantek> darobin: in that case, just install NoScript. if a site doesn't work, use a different one.
- # [23:54] <darobin> ok, you have a point gsnedders
- # [23:54] <darobin> tantek: I think a better solution is the one they advocate "Tell Google Adsense this is unacceptable"
- # [23:54] <darobin> AdSense is basically using 30ms of JS every second
- # [23:55] <darobin> times the number of tabs in the world this is run on, that's a lot of energy
- # [23:55] <tantek> where do you think all that distributed computing was going to come from? their own compute farms? nah. why bother with a compute cloud when you can hijack 30ms of user browser time every 1s?
- # [23:55] <jgraham> Well in this case I think it's more than that
- # [23:55] <tantek> the cloud … it's made of users!
- # [23:56] <jgraham> (it was 25ms on a phone, so probably less on a desktop, but still)
- # [23:56] <darobin> hehe
- # [23:56] <tantek> SoylentCloud™
- # [23:56] <jgraham> To be fair, doing compute on the client is totally legitimate. Running any ad related script in scroll handlers isn't
- # [23:56] <gsnedders> are there any UAs people actually use that use anything except screen or print media types?
- # [23:57] * Quits: eric_carlson (~ericc@17.202.49.94) (Ping timeout: 256 seconds)
- # [23:57] <jgraham> But the impression I get is that for the (biased) sample of sites they looked at, people had *no idea* what was actually running
- # [23:57] <gsnedders> jgraham, darobin: IIRC AdSense have stats on how often the ads scroll into view, I presume that's what it's there for… and that involves touching CSSOM and that's dear
- # [23:58] <jgraham> Yeah, well they clearly can't do that the way they are doing it without killing performance of the platform
- # [23:59] <jgraham> Oh hurrah, roc posted this to dev.platform
- # Session Close: Tue Mar 31 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