| 01:12 | <Oksana> | hsivonen: I was wondering if you could provide tips on requesting Maemo Source Code from Nokia (or Microsoft, as it may be)? https://hsivonen.fi/maemo-src/ You have source code for osso-rss-feed-reader version 1.2.31-1, while I am wondering about version 1.8.22-2 . Of course, I would prefer getting the latest source codes of _everything_ , if possible. |
| 04:57 | <annevk_> | Multimaps :-) At some point we'll redo FormData, URLSearchParams, and Headers in terms of them |
| 04:57 | <annevk> | Ugh that underscore |
| 10:42 | <hsivonen> | Oksana: I put the text of my request letter at https://hsivonen.fi/maemo-src/request.html . Feel free to adapt that text to the facts of your case. The GPL offer notice was in some sort of system-wide about box. |
| 12:36 | <n0a___> | Hi, Iv been redirected here, anyone knows what's the usage for the "xmlhttprequest" context? cf https://fetch.spec.whatwg.org/#concept-request-context |
| 12:42 | <JakeA> | n0a___: yeah, it's not xmlhttprequest, it's fetch. It means a serviceworker can detect the rough type of the request, which is useful when determining what kind of fallback content to show. It's also useful for CSP when deciding whether to block content or not. Also useful for network stack when deciding priority |
| 12:45 | <n0a___> | JakeA: sorry but I understand for most of the other values |
| 12:45 | <n0a___> | but not for this one or others connect-src ones |
| 12:45 | <n0a___> | in these cases does it refer to the context of the destination? |
| 12:46 | <n0a___> | or do you have a simple use case? |
| 12:46 | <JakeA> | n0a___: that big list is likely to be boiled down to something simpler. See https://github.com/whatwg/fetch/issues/93#issuecomment-126686379 |
| 12:47 | <n0a___> | hum |
| 12:48 | <n0a___> | so ur saying these connect-src context values will be dropped? |
| 12:49 | <n0a___> | in short what is the use case for any connect-src scenario using fetch? |
| 12:49 | <n0a___> | ur fetching from xhr? |
| 12:49 | <n0a___> | that doesn't make sense to me |
| 12:49 | <n0a___> | you are fetching the url string to feed to xhr? |
| 12:49 | <JakeA> | fetch('/hello') would have a context of "connect" in that proposal |
| 12:49 | <JakeA> | as would xhr requests |
| 12:52 | <n0a___> | JakeA: so "processor" in your comment corresponds to the context property? |
| 12:52 | <JakeA> | annevk: Israel from Microsoft, what was his surname? (trying to find his email address) |
| 12:52 | <annevk> | JakeA: see pm |
| 12:52 | <JakeA> | n0a___: yeah, the context property is likely to be replaced by something like the things in that github comment |
| 12:53 | <n0a___> | that's a good thing because it seems easier to grasp |
| 12:53 | <n0a___> | is the current context property already supported by current browsers? |
| 12:54 | <n0a___> | well I could check |
| 12:55 | <n0a___> | JakeA: context is already supported by browsers so my question remains what does it mean to have an xhr context? |
| 12:56 | <JakeA> | n0a___: which browsers support context? |
| 12:56 | <n0a___> | chrome |
| 12:56 | <n0a___> | new Request({}) |
| 12:57 | <n0a___> | I dunno if it supports the values though |
| 12:57 | <n0a___> | would require more tests |
| 12:58 | <JakeA> | n0a___: Chrome would drop 'context' and move to the new thing (which may still be called 'content') |
| 12:58 | <JakeA> | I don't think the current implementation is useful enough to create a breaking change |
| 12:58 | <n0a___> | JakeA: I still need to understand what are those src-connect value today |
| 12:59 | <n0a___> | of course if they are not supported that's another sotory |
| 12:59 | <JakeA> | n0a___: I don't think I understand your question. Are you asking what the context value would be in XHR? Do you mean in the current spec or the thing we're proposing on github? |
| 12:59 | <n0a___> | *story |
| 12:59 | <JakeA> | I don't think they're supported |
| 13:00 | <n0a___> | I am not proposing anything on GitHub, I want to understand why you would use the value "xmlhttprequest" for the property context of a request object |
| 13:01 | <n0a___> | what's the use case that supports it |
| 13:01 | <JakeA> | n0a___: well, the proposal on GitHub is to use "connect" as defined as CSP |
| 13:02 | <JakeA> | The use cases are at https://github.com/whatwg/fetch/issues/93#issuecomment-126653941 |
| 13:02 | <annevk> | n0a___: it gives the service worker the ability to impose policies based on who requested the resource |
| 13:02 | <annevk> | n0a___: but as several folks pointed out, we're going to change how this works |
| 13:02 | <n0a___> | annevk: sorry to be so dense but what are the resorces in that case? |
| 13:02 | <JakeA> | n0a___: anything a page requests |
| 13:02 | <n0a___> | resources why do you need to set specifically to xhr? |
| 13:03 | <annevk> | n0a___: do you know what a service worker is? |
| 13:03 | <n0a___> | yes |
| 13:03 | <JakeA> | n0a___: we're not specifically setting xhr, the proposal is to use "connect" as defined by CSP |
| 13:03 | <annevk> | n0a___: and in particular how it can intercept fetches? |
| 13:03 | <annevk> | n0a___: "xmlhttprequest" is used when the service worker intercepts a fetch coming from XMLHttpRequest |
| 13:03 | <JakeA> | by using what's already defined by CSP, we're not really inventing much new |
| 13:04 | <n0a___> | OHHH so it's not fetch() |
| 13:04 | <n0a___> | but xhr using fetch internally? |
| 13:04 | <annevk> | n0a___: everything that does requests uses Fetch internally, but not necessarily the fetch() API |
| 13:04 | <annevk> | JakeA: I don't think "connect" is a value we should use |
| 13:05 | <n0a___> | ok but I wasn't interested in internal stuff… now I get it |
| 13:05 | <annevk> | JakeA: the type stuff made much more sense to me anyway |
| 13:05 | <annevk> | I guess I should try to resolve this next week |
| 13:06 | <JakeA> | annevk: I agree that "connect" is a bad name. I was just reusing CSP for consistency |
| 13:06 | <n0a___> | you should really differentiate fetch [intern] and fetch global |
| 13:06 | <n0a___> | it's quite confusing |
| 13:06 | <annevk> | n0a___: well, fetch() and fetch |
| 13:07 | <annevk> | n0a___: but... open to suggestions I suppose |
| 13:07 | <n0a___> | just a remark, you do whatever you want with it |
| 13:08 | <annevk> | n0a___: I agree with your remark, but I don't really have any better ideas |
| 13:08 | <JakeA> | I go with "fetch event" "fetch spec" and "fetch api" verbally |
| 13:09 | <n0a___> | maybe be very verbose whenever it could be confusing if it's taken out of context |
| 13:09 | <n0a___> | I see ppl quoting the spec and being confused |
| 13:10 | <n0a___> | or just add examples, always work :) |
| 13:12 | <annevk> | n0a___: well if you're already in the spec you can read https://fetch.spec.whatwg.org/#preface which should make things pretty clear |
| 13:13 | <n0a___> | like I said, ppl do quote the spec so it's out of context |
| 13:13 | <n0a___> | https://code.google.com/p/chromium/issues/detail?id=455116 |
| 13:17 | <JonathanNeal> | I’m pushing svg4everybody v2 today. Any last minute pass over the README.md is very welcome: https://github.com/jonathantneal/svg4everybody/tree/feature/2.0.0 |
| 13:17 | <n0a___> | gosh this is messy now they want to remove it https://code.google.com/p/chromium/issues/detail?id=515786 |
| 13:19 | <n0a___> | reminds me of IE5 and document fragments |
| 13:19 | <n0a___> | implemented removed reimplemented |
| 13:20 | <JakeA> | n0a___: not too messy, we knew shipping aggressively may mean making breaking changes. I haven't seen a lot of use of it, although we're going to gather evidence |
| 13:21 | <n0a___> | well I am starting |
| 13:21 | <n0a___> | but something that puzzled me is the lack of type for the Response object |
| 13:22 | <n0a___> | as if you have to know the type |
| 13:23 | <n0a___> | and even more confusing is that we have https://developer.mozilla.org/en-US/docs/Web/API/Response/type |
| 13:24 | <JakeA> | n0a___: what type do you want? |
| 13:24 | <JakeA> | as in, what information are you wanting? |
| 13:24 | <JakeA> | If it's content type, look at the headers |
| 13:24 | <n0a___> | blob, json, text etc |
| 13:24 | <n0a___> | why? the content header could lie |
| 13:26 | <JakeA> | n0a___: there's no such type as blob |
| 13:26 | <JakeA> | that's what you read the content into, but all types can be read into blob |
| 13:27 | <JakeA> | sounds like you're wanting something to read the data and determine the type? |
| 13:27 | <n0a___> | https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest#xmlhttprequest-responsetype |
| 13:27 | <JakeA> | But take "Hello <b>everyone</b>" - is that plain text or HTML? |
| 13:27 | <JakeA> | n0a___: that's something you set for how you want the response to be processed |
| 13:27 | <n0a___> | I don't really care about the values |
| 13:27 | <n0a___> | just a string with the type |
| 13:28 | <JakeA> | It's a string you set, not a string you read |
| 13:28 | <n0a___> | right |
| 13:28 | <n0a___> | so ur saying there's no way to forge the header? |
| 13:28 | <JakeA> | Is that what you want? |
| 13:28 | <JakeA> | Let's start again |
| 13:28 | <n0a___> | you must be right |
| 13:28 | <JakeA> | Are you looking for a way to say "I want to read this response as JSON"? |
| 13:29 | <n0a___> | the responsetype is set before the send |
| 13:29 | <n0a___> | sorry about that |
| 13:29 | <JakeA> | Yep |
| 13:29 | <n0a___> | no I wanted to know the type of the received data without having to know it or use the header |
| 13:30 | <JakeA> | With fetch you don't set a response type, you get a response and read the body how you want, eg fetch(url).then(r => r.json()) |
| 13:30 | <n0a___> | still you need to know what ur receiving |
| 13:30 | <JakeA> | Isn't really possible I'm afraid. Some types can be detected, but not all |
| 13:30 | <JakeA> | Back to the example: "Hello <b>everyone</b>" - is that plain text or HTML? |
| 13:30 | <JakeA> | Or XML |
| 13:30 | <n0a___> | a data-agnostic receiving function would be complicate |
| 13:31 | <n0a___> | well it's a string :) |
| 13:31 | <JakeA> | Impossible I reckon |
| 13:31 | <JakeA> | n0a___: You're still relying on headers to decide that |
| 13:34 | <n0a___> | I dunno if you are working on the spec yourself but there's something else I had a hard time with, it's the non object values of https://fetch.spec.whatwg.org/#headers-class |
| 13:34 | <n0a___> | I dunno if I am the target of the spec |
| 13:34 | <n0a___> | but it seemed pretty obscure |
| 13:34 | <n0a___> | probably requires webidl knoledge to graps |
| 13:35 | <n0a___> | graps* |
| 13:35 | <n0a___> | grasp third try |
| 13:37 | <annevk> | n0a___: I write the spec, but yeah, you need to know IDL |
| 13:58 | <n0a___> | JakeA: it's implemented https://codereview.chromium.org/1060033002/diff/60001/Source/modules/fetch/Request.cpp#newcode296 |
| 13:58 | <n0a___> | so I have to support it sadly for you :) |
| 14:06 | <JakeA> | n0a___: I'm not sure what you're saying. Why do you need to support it? |
| 14:06 | <n0a___> | I don't understand sorry, if it's implemented that's what you have to use |
| 14:07 | <JakeA> | You don't have to use everything that's implemented |
| 14:07 | <n0a___> | until something else replace it |
| 14:07 | <JakeA> | And we're likely to remove that feature |
| 14:07 | <JakeA> | What are you trying to do? |
| 14:08 | <n0a___> | just reading the spec |
| 14:08 | <n0a___> | thx for your support |
| 14:09 | JakeA | goes for a lie down |
| 15:06 | <wanderview> | annevk: (or JakeA if you're up) if I event.respondWith(Response.redirect(url) where event.request.redirect==follow, should I get another fetch event? reading the spec is seems I should, but I don't trust anything about my interpretation now |
| 15:09 | <JakeA> | wanderview: I agree with your reading, you'll get another fetch |
| 15:10 | <wanderview> | JakeA: and even if the redirect is same origin, its done as a CORS request? (seems CORS flag is always set... seems weird for same origin) |
| 15:13 | <JakeA> | wanderview: "CORS flag set if set.", so it only sets CORS is the original was |
| 15:13 | <wanderview> | JakeA: arg... I actually parsed that odd language yesterday |
| 15:14 | <JakeA> | Took me a couple of reads, but then, I have a \o/ deskbeer \o/ |
| 15:15 | <wanderview> | ha |
| 15:15 | <wanderview> | thanks |
| 15:53 | <annevk> | If you have suggestions for rewording that, I'm all ears (or eyes, really) |
| 15:54 | <annevk> | But yeah, if you get a redirect from the service worker, fetch will follow it and go into the service worker again |
| 16:43 | <n0a___> | annevk: just a quick question I don't wanna add a dupe issue on github, is there a ticket which covers the fact that the default for request modee should be 'same-orgin' (and not "no-cors") which would imply an opaque filtered response (which is not desired obviously)? |
| 16:44 | <n0a___> | I don't think https://github.com/whatwg/fetch/issues/101 covers my demand |
| 16:44 | <annevk> | n0a___: neither of those is the default iirc |
| 16:45 | <n0a___> | "A request has an associated mode, which is one of "same-origin", "no-cors", "cors", and "cors-with-forced-preflight". Unless stated otherwise, it is "no-cors"." |
| 16:45 | <n0a___> | unless there's another source for the spec that I am not aware of |
| 16:45 | <annevk> | n0a___: ah, that has to be the default since most stuff requires "no-cors" |
| 16:46 | <annevk> | n0a___: but for fetch() the default is "cors" |
| 16:46 | <n0a___> | so the default listed there are not for fetch |
| 16:46 | <n0a___> | I should look elsewhere then |
| 16:47 | <annevk> | The defaults there are for all features |
| 16:47 | <annevk> | The API is defined in https://fetch.spec.whatwg.org/#fetch-api |
| 16:47 | <n0a___> | Otherwise Set request's response tainting to "cors". |
| 16:48 | <n0a___> | k thx you should put somewhere the default state of a request for fetch |
| 16:49 | <n0a___> | (all of them instead of having to check each one) |
| 16:53 | <annevk> | Yeah, that would make sense, one day |
| 17:01 | <wanderview> | annevk: I think instead of "CORS flag set if set", I would understand "with the current CORS flag value" better. |
| 17:01 | <annevk> | wanderview: but set/unset is not a value |
| 17:02 | <wanderview> | annevk: how is it not a boolean value? |
| 17:02 | wanderview | senses a lesson in spec terminology coming on. |
| 17:03 | <annevk> | wanderview: gotta go, but yeah, it's basically the way it's phrased |
| 17:09 | <n0a___> | can't ctrl-f numbers since ur using lists :) |
| 17:26 | <ccardona-work> | Good morning WHATWG crew o/ |
| 18:57 | <TabAtkins> | Am I reading this correctly, that when you dispatch an event, all the event handlers run synchronously at that point in your algorithm? |
| 18:57 | <TabAtkins> | annevk: ^^^ |
| 18:58 | <TabAtkins> | It *looks* like that's the case from the DOM spec, but I was under the impression that firing an event just queued up the event handlers onto the task queue, so they don't run until the next time you hit the event loop. |
| 20:35 | <JakeA> | TabAtkins: I thought it was sync |
| 20:35 | <JakeA> | In fact, IDB relies on it being sync |
| 20:40 | <jsbell> | JakeA: Agree that it's sync, but where in IDB? |
| 20:41 | <jsbell> | (since in IDB that triggers events happens async) |
| 20:41 | <smaug____> | TabAtkins: event dispatching is always sync |
| 20:41 | <jsbell> | (... in IDB everything that triggers events...) |
| 20:41 | <TabAtkins> | Okay, cool, that means I'm wrong and have to swap the ordering of some stuff in Font Loading. ^_^ |
| 20:41 | <smaug____> | if you need asyncness, you queue a task to dispatch event... |
| 20:43 | <JakeA> | jsbell: step 4 of http://w3c.github.io/IndexedDB/#fire-a-success-event - if events were async the transaction would be closed onsuccess |
| 20:44 | <jsbell> | JakeA: ah, yes. |
| 20:45 | <JakeA> | That's my least favourite line of IDB. If only it was queue a microtask. |
| 20:46 | <JakeA> | Then you could build an OK promise API on top |
| 20:50 | <jsbell> | JakeA; It does seem likely it's web-compatible to change it |
| 20:51 | <JakeA> | jsbell: that'd be great |
| 20:51 | <jsbell> | JakeA: although some devs don't want anything that'd make transaction commits slower. To them I say: https://gist.github.com/inexorabletash/d55a6669a040e92e47c6 |
| 20:51 | <jsbell> | JakeA: file a spec bug so we don't forget to discuss? |
| 20:53 | <JakeA> | jsbell: I'll pick it up before Monday (I've got a tab open for the Chrome & Firefox bugs so that'll remind me when I'm next at the laptop) |
| 20:53 | <jsbell> | cool |
| 20:54 | <jsbell> | sicking: who's the best Moz contact for IDB at the moment? (specifically I want to discuss shipping getAll) |
| 20:55 | <sicking> | jsbell: i think it might be Jan Varga (jvarga@moz). Though you should include Andrew Overholt (overholt@moz) as well |
| 20:55 | <jsbell> | thx |
| 20:55 | <sicking> | jsbell: i think we would be for it though |
| 20:55 | <jsbell> | cool; running away to an appt now, TTYL |