| 01:05 | <sangwhan> | tantek: It went through TAG review a couple months ago, so I've seen it - what about it? |
| 01:15 | <sangwhan> | TL:DR; summary is letting <video> to be thrown at your Apple TV or equivalent OTT box - has some worms in terms of cross browser/device pair interop though |
| 01:51 | <MikeSmith> | sangwhan: do you still build Chrome and if some are you using jumbo builds and if so how much has it reduced your build time in your environment |
| 01:51 | <MikeSmith> | in particular, how much has it reduced it for a full build from a clean working directory |
| 01:52 | <MikeSmith> | *still build Chrome and if *so* are you using jumbo builds |
| 03:53 | <DDK> | Does anyone here know how to hack Elvenar to get mo |
| 03:53 | <DDK> | more diamonds* |
| 04:22 | <tantek> | sangwhan: the attribute disableRemotePlayback sounded vaguely DRMish so I thought I'd ask critical crowd like here :) |
| 04:40 | <sangwhan> | MikeSmith: last time I had to build chrome I recall using sumo, but that was quite a while ago. Not sure if sumo is jumbo based - sounds dangerous to do on Chrome. |
| 05:37 | <MikeSmith> | annevk: about “Credentials |
| 05:37 | <MikeSmith> | are HTTP cookies, TLS client certificates, and authentication entries.” |
| 05:37 | <MikeSmith> | in the Fetch spec |
| 05:37 | <MikeSmith> | *authentication entries* is a link just to https://fetch.spec.whatwg.org/#authentication-entry |
| 05:38 | <MikeSmith> | which dfn does not normatively include proxy-authentication entries |
| 05:39 | <MikeSmith> | > An authentication entry and a proxy-authentication entry are tuples of username, password, and realm, associated with one or more requests. |
| 05:41 | <MikeSmith> | so should the definition of credentials instead be: |
| 05:41 | <MikeSmith> | > Credentials are HTTP cookies, TLS client certificates, authentication entries, and proxy-authentication entries. |
| 05:43 | <MikeSmith> | annevk: or to help clarify and fix that open issue: |
| 05:43 | <MikeSmith> | > Credentials are HTTP cookies, TLS client certificates, and, for HTTP Authentication, authentication entries and proxy-authentication entries. |
| 05:49 | <MikeSmith> | or even better: |
| 05:49 | <MikeSmith> | > Credentials are HTTP cookies, TLS client certificates, and, for HTTP Authentication, authentication entries and proxy-authentication entries. [COOKIES] [TLS] [HTTP-AUTH] |
| 07:30 | <MikeSmith> | annevk: oh, does the definition of credentials intentionally not include proxy authentication? |
| 07:31 | <MikeSmith> | because I notice that XHR defines “user credentials” as not including proxy authentication |
| 07:32 | <MikeSmith> | > The term user credentialsfor the purposes of this specification means cookies, HTTP authentication, and TLS client certificates. Specifically it does not refer to proxy authentication or the Origin header. |
| 07:32 | <MikeSmith> | ... |
| 07:33 | <MikeSmith> | or are what the Fetch spec defines as “credentials” and what the XHR spec defines as “user credentials” not actually exactly the same thing? |
| 07:36 | <annevk> | MikeSmith: hey |
| 07:36 | <annevk> | MikeSmith: I'm not sure about proxies |
| 07:36 | <annevk> | MikeSmith: I basically have never played with them, but as far as I know user agents consider them part of credentials; though that might have changed or might differ across user agents |
| 07:37 | <annevk> | MikeSmith: it seems safest to exclude them as long as we're not sure |
| 07:38 | <MikeSmith> | OK but don' |
| 07:38 | <MikeSmith> | oofs |
| 07:39 | <MikeSmith> | OK but don't see how “it seems safest to exclude them as long as we're not sure” follows from “as far as I know user agents consider them part of credentials”.. |
| 07:39 | <MikeSmith> | but anyway I will update the Fetch PR to (re)exclude them |
| 07:42 | <annevk> | MikeSmith: well that was going from memory |
| 07:42 | <MikeSmith> | ok |
| 07:42 | <annevk> | MikeSmith: if Fetch and XHR don't include proxies I'd rather we continue to do so |
| 07:44 | <MikeSmith> | hai |
| 07:44 | <MikeSmith> | will do the XHR PR in a bit (to change it to just reference the Fetch dfn) |
| 09:05 | <qswz> | I'm trying to implement ] [ mmn ] [ tyoshino ] |
| 09:05 | <qswz> | I'm trying to implement https://dom.spec.whatwg.org/#dom-childnode-replacewith here: https://github.com/caub/jsdom/blob/a/lib/jsdom/living/nodes/ChildNode-impl.js#L53-L78 |
| 09:06 | <qswz> | but for the moment it makes no sense in terms of code |
| 09:06 | <qswz> | for .after and .before I think it's good, but .replaceWith's spec is harder to understand |
| 09:20 | nox | qswz: What's your issue? |
| 09:54 | <zcorpan> | qswz: rows 69..70 don't match up with the spec, right? |
| 10:31 | <qswz> | zcorpan: no, it doesn't |
| 10:32 | <qswz> | until then it was following it, but after I'm super confused |
| 10:34 | <qswz> | I understand it's problematic if nodes contains the context object |
| 10:34 | <qswz> | so I tried something |
| 16:23 | <domfarolino> | annevk: in what case would the condition in step 14 substep 1 of request constructor ever be triggered? I ask because it seems we can't ever construct a Request object whose mode is "navigate" without throwing a TypeError right? |
| 16:24 | <wanderview> | domfarolino: I think you can in a FetchEvent handler with new Request(evt.request), no? |
| 16:24 | <wanderview> | in that case the input Request object was created by the browser for FetchEvent.request |
| 16:30 | <domfarolino> | wanderview: so evt.request would have to be a request whose mode is "navigate"? |
| 16:32 | <annevk> | domfarolino: yeah, you get that in a service worker |
| 16:39 | <domfarolino> | wanderview: annevk: ok that makes sense, how exactly is this request whose mode is "navigate" constructed then? Because if the browser constructs it internally, doesn't that still sort of violate step 18 where we throw? |
| 16:39 | <domfarolino> | In other words, do internally constructed objects not necessarily follow the constructor steps outlined in the spec? |
| 16:40 | <domfarolino> | hm that might be a naïve question |
| 16:45 | <annevk> | domfarolino: yup, browser has special powers |
| 16:45 | <annevk> | domfarolino: it can just create a Request object instance and then back it with an arbitrary request |
| 16:46 | <annevk> | domfarolino: this pattern is used a lot, but we haven't been very formal about it thus far; at some point IDL will define object allocation/creation, which should make it a little clearer whenever it happens |
| 16:52 | <domfarolino> | annevk: Ok so I believe I've heard that the objects defined in fetch spec are used in general browser resource loading (all managed internally)...so does this mean when the browser "fetches" things like images and stylesheets, it creates request and possibly other objects under the hood, just it its own way? |
| 16:52 | <domfarolino> | annevk: Gotcha, thanks. Ah yeah that sounds pretty helpful! |
| 16:53 | <annevk> | domfarolino: yes |
| 16:53 | <annevk> | domfarolino: that's also why there's a distinction between a "request" and a Request object, to some extent |
| 16:54 | <annevk> | domfarolino: we could potentially merge them into one, but it's a little weird for non-JavaScript algorithms to pass around JavaScript objects, whereas abstract concepts seems a bit more natural |
| 16:55 | <annevk> | again though, largely convention, not formalized |
| 16:57 | <domfarolino> | annevk: Right that makes sense. That's what was a tad confusing to me at first because I figured if a browser constructed this object internally (i.e. not in JavaScript), it couldn't necessarily throw a TypeError, so it must not be following the rules. So when we say "request" instead of Request object, do we expect internals to actually create an object of type Request, just in its own way? Or is it valid for the |
| 16:57 | <domfarolino> | internal representation to be whatever the heck it wants, so long as objects exposed to the DOM are compliant |
| 16:59 | <annevk> | domfarolino: a request doesn't necessarily have an associated Request |
| 16:59 | <annevk> | domfarolino: service workers ends up creating a Request object for them |
| 17:00 | <annevk> | domfarolino: that's how they end up exposed, but the way it creates those Request objects doesn't go through the constructor, it just allocates a shell and fills in the slots |
| 17:00 | <domfarolino> | annevk: Right, but when an image is fetched let's say, can we expect somewhere in c++ land is calling `new Request(...)`, even though there is no formal requirement to do so |
| 17:00 | <domfarolino> | Ah ok that's what I was getting at yes |
| 17:01 | <annevk> | domfarolino: for <img> I'd expect C++^H^H^H^HRust land to do something like create_request() which creates some internal object which maps to the request concept |
| 17:02 | <annevk> | It wouldn't involve the Request class at all, unless there's a service worker |
| 17:07 | <domfarolino> | annevk: ok, so it won't involve the literal class, it would just need the attributes defined in https://fetch.spec.whatwg.org/#concept-request |
| 17:08 | <annevk> | smaug____: if you happen to know why setAttribute("test", sameValueAsNow) creates a mutation record, maybe reply to https://github.com/whatwg/dom/issues/520? |
| 17:09 | <annevk> | domfarolino: yeah, could be a struct or whatever |
| 17:09 | <annevk> | domfarolino: or even just parameters, as long as the end result is the same |
| 17:10 | <annevk> | domfarolino: implementations can pretty much do whatever they want as long as they give the same outputs |
| 17:11 | <annevk> | domfarolino: see also paragraph after example here https://infra.spec.whatwg.org/#algorithms |
| 17:12 | <domfarolino> | Right, as long as main fetch can perform with whatever the input “request” is, all is well. |
| 17:14 | <domfarolino> | annevk: excellent that makes sense, thank you |
| 17:26 | <domfarolino> | Yeah the differentiation between “request” and Request makes a lot of sense, I guess wasn’t something I put much thought into before |