| 13:41 | <wanderview> | JakeA: reading your reply here about the "first-party-cookies" and SW: https://mail.google.com/mail/u/0/#label/blink-dev/14c314afd2174c91 |
| 13:41 | <wanderview> | JakeA: just FYI, I think we are going to disable SW interception completely when the user has "disable third-party cookies" preference enabled |
| 13:41 | <wanderview> | not quite the same, because its not based on a header request... but seems similar |
| 13:42 | <wanderview> | JakeA: I mean, disable SW interception completely for third party iframes |
| 13:43 | <JakeA> | Phew! |
| 13:43 | <JakeA> | I was worried for a second there |
| 13:44 | <JakeA> | wanderview: that seems ok, what's the attack? That the iframe request can look at the referrer and track? |
| 13:45 | <wanderview> | JakeA: well, we want to disable IDB and other storage APIs for 3rd party iframes when the pref is set... to prevent tracking... but once we are in the SW we have no way to tell if a third party iframe is involved |
| 13:45 | <wanderview> | we want to completely hide the API endpoints on the global... so we need to do it at SW spin-up |
| 13:47 | <wanderview> | JakeA: also, I don't know if you have an opinion on this issue, but its the other main thing we have to deal with to enable IDB on SW: https://github.com/slightlyoff/ServiceWorker/issues/648#issuecomment-78621258 |
| 13:47 | <wanderview> | we currently don't allow IDB in sandboxed iframes at all |
| 13:53 | <JakeA> | Hmm good point, I wonder what Chrome does |
| 15:52 | <TabAtkins> | gsnedders: Thank god, I can finally submit a PR for the "converting XML name, but I wont' tell you which one" error message. |
| 15:53 | <Ms2ger> | Hm? |
| 16:58 | <JakeA> | Domenic: why is the input for TextDecoder decode optional? Is that in preparation for TextDecoder to become a transform stream? |
| 16:59 | <Ms2ger> | JakeA, for signalling EOF |
| 16:59 | <Ms2ger> | I though |
| 16:59 | <Ms2ger> | t |
| 17:00 | <JakeA> | ahh ok |
| 17:01 | <Ms2ger> | I may also have that completely backwards, though :) |
| 17:09 | <JakeA> | Domenic: if I'm streaming a string & reading the chunks with TextDecoder, is there anything I can do about a chunk landing mid-way through a multibyte codepoint? |
| 17:09 | <JakeA> | I guess I really want a TextDecoder transform stream |
| 17:15 | <wanderview> | JakeA: yea... seems there should be a TextDecoder stream that internally re-chunks |
| 17:19 | <JakeA> | wanderview: TextDecoder has a 'stream' option, but that appears to read the whole stream |
| 17:19 | <JakeA> | ohhh no wait |
| 17:19 | <JakeA> | "If options's stream is true, the method can be invoked multiple times to process a fragmented stream." |
| 17:20 | <wanderview> | JakeA: what are you looking at? |
| 17:20 | <JakeA> | https://encoding.spec.whatwg.org/ |
| 17:23 | <JakeA> | I can't figure out how to use it |
| 17:23 | <JakeA> | var decoder = new TextDecoder(); |
| 17:24 | <JakeA> | decoder.decode(???, {stream: true}); |
| 17:24 | <JakeA> | Then keep calling decoder.decode() to get more data |
| 17:24 | <JakeA> | but I can't figure out that first param "BufferSource" |
| 17:25 | <JakeA> | It can't be a stream, as decode() is sync and stream reading isn't |
| 17:25 | <wanderview> | JakeA: maybe annevk knows |
| 17:25 | <wanderview> | JakeA: the spec doesn't seem to reference whatwg-streams, so I assume its not related? |
| 17:27 | <JakeA> | wanderview: I think you're right, stream means something different here |
| 17:29 | <wanderview> | JakeA: does anyone implement this spec yet? or it mainly meant as something other specs can refer to? |
| 17:29 | <JakeA> | wanderview: it appears to be in Canary |
| 17:30 | <wanderview> | JakeA: http://heycam.github.io/webidl/#common-BufferSource |
| 17:30 | <wanderview> | I guess it should link there |
| 17:30 | <JakeA> | Aha! |
| 17:30 | <wanderview> | the "copy to" link in the decode() function goes to that spec |
| 17:39 | <gsnedders> | TabAtkins: :) |
| 17:45 | <JakeA> | Ok, worked it out. var d = new TextDecoder(); d.decode(uint8Array, {stream: true}); /* returns whole chars, doesn't cut off partial utf8 chars */ d.decode(uint8Array, {stream: true}); /* this is added to the data it had so far */ |
| 17:46 | <JakeA> | wanderview ^ |
| 17:47 | <jsbell> | JakeA: I'm lacking context but I can help w/ text encoding API stuff. :) |
| 17:47 | <JakeA> | jsbell: I'm playing with the streams API, so I'm getting chunks as uint8array, I'm trying to read this as text in a way that don't fail if the chunk ends/starts on parts of a multibyte char |
| 17:48 | <jsbell> | JakeA: Yep, {stream:true}. And you probably want to call d.decode() (no i.e. default args) at the end of the stream to flush |
| 17:49 | <jsbell> | so that if you have a partial sequence it correctly generates a U+FFFD |
| 17:50 | <jsbell> | JakeA: I haven't had a chance to soak in streams; glad someone's trying to compose encoding+streams |
| 17:50 | <JakeA> | jsbell: like this? https://jsbin.com/gowaze/quiet |
| 17:50 | <jsbell> | JakeA: lgtm |
| 17:50 | <JakeA> | jsbell: ideally in future this should be stream.pipeThrough(new TextDecoder) I think |
| 17:51 | <wanderview> | is the text regarding the stream option correct? https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder/decode |
| 17:52 | <jsbell> | Um... not really correct. Not very helpful anyway.... |
| 17:52 | <wanderview> | yea |
| 17:53 | <wanderview> | JakeA: and I guess everyone supports it except IE/safari |
| 17:53 | <jsbell> | I has polyfill: https://github.com/inexorabletash/text-encoding |
| 17:54 | <wanderview> | nice |
| 17:56 | <jsbell> | Spec isn't much clearer on 'stream' but that's not the spec's job. :) MDN could say: "A Boolean flag indicating that additional data to decode will follow in subsequent calls to decode(). Set to true if processing the data in chunks, and false for the final chunk or if the data is not chunked" or something |
| 18:04 | <Domenic> | JakeA: yeah the plan is to do "encoding api v2" when we have all the parts of streams figured out |
| 18:04 | <Domenic> | Possibly add some simpler static methods for one-shot encoding/decoding while we're there |
| 18:04 | <Domenic> | I think I asked annevk about this and he said that TextEncoder instances didn't keep any state, and so I'm not sure what to do about landing halfway through multibyte content :-S |
| 18:05 | <JakeA> | Domenic: jsbell: so does my use of decoder make sense here https://jsbin.com/gowaze/edit?js |
| 18:05 | <JakeA> | Domenic: they retain a stream, so there's some state |
| 18:05 | <JakeA> | "stream" |
| 18:05 | <JakeA> | calling .decode(input, {stream:true}) pushes to that internal stream |
| 18:06 | <Domenic> | gah jsbin I want to love you but why is the content area so small (jshint + giant features banner) |
| 18:06 | <Ms2ger> | bit.ly/livedom :) |
| 18:07 | <Domenic> | JakeA: in general you'll either have { value: x, done: false } or { value: undefined, done: true }, so you can simplify a bit |
| 18:07 | <Domenic> | but yeah looks solid in general |
| 18:08 | <JakeA> | Domenic: what simplification? Drop the || []? I was worries the explicit undefined would be counted as a value |
| 18:09 | <JakeA> | But that doesn't appear to be the case, cool |
| 18:09 | <Domenic> | JakeA: I was thinking, test result.done early and bail immediatley if you see it |
| 18:09 | <Domenic> | then assume it's false from then on |
| 18:10 | <JakeA> | Domenic: I don't think I can, because partialCell may still contain data. Also calling decode will flush any remaining data. |
| 18:11 | <Domenic> | Ah, interesting, I see. |
| 18:12 | <Domenic> | You don't need to pass { stream: true } for previous chunks, only for the last one? |
| 18:13 | <Domenic> | I guess just worth testing this thing on some real data and we'll know the answer :P |
| 18:17 | <jsbell> | JakeA: I may have lost context, but {stream: result.done} seems like it should be {stream: !result.done} ?? |
| 18:18 | <Domenic> | right, I think that is what I was implying as well |
| 18:18 | <jsbell> | stream is basically !flush |
| 18:21 | <jsbell> | <3 wanderview for updating MDN already |
| 18:21 | <wanderview> | np! thanks for the text :-) |
| 18:25 | <jsbell> | wanderview: if you're feeling really keen, you can crib the examples from https://github.com/inexorabletash/text-encoding |
| 18:26 | <wanderview> | jsbell: thanks... I'll see if I can find the time later today |
| 18:55 | <JakeA> | jsbell: oh wow, yes, don't know how that crept in |
| 18:56 | <JakeA> | I can code, honest |
| 18:56 | <JakeA> | I can code, honest |
| 23:06 | <othermaciej> | is there anyone around who understands how microtasks are supposed to work? |
| 23:06 | <othermaciej> | I am finding the spec confusing |
| 23:19 | <jsbell> | othermaciej: maybe? what's up? |
| 23:22 | <othermaciej> | jsbell: is there anything that causes microtasks to be performed after an event handler, function-based timer, or other non-script-based callback is run? |
| 23:23 | <othermaciej> | it sure sounds like this algorithm should run after such callbacks: https://html.spec.whatwg.org/#clean-up-after-running-a-callback |
| 23:24 | <othermaciej> | but I could not find anything that would cause it to happen; only seems to happen for stuff evaluating bare script code, like <script> or a timer with a string instead of a function |
| 23:45 | <jamesr___> | othermaciej: https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9 step 7 perhaps? |
| 23:46 | <jamesr___> | there are various other invocations of the "Perform a microtask checkpoint." text, for example in the "spin the event loop" section |
| 23:49 | <jamesr___> | but the task one in the processing model should cover event handler, function-based timer and other non-script-based callbacks |
| 23:49 | <jamesr___> | since those are all tasks |
| 23:52 | <jsbell> | (sorry was afk). Agreed - anything that isn't covered by that sounds like a spec bug. |
| 23:55 | <jsbell> | jgraham: I've lost track of what the actual question is in the serviceworker/wpt thread |
| 23:57 | <jgraham> | jsbell: The latest messages are about whether the tests can be written to run on https rather than on http |
| 23:57 | <jgraham> | AIUI the tests currently rely on running on a hostname that's whitelisted as allowing SW on http i.e. localhost or 127.0.0.1 |
| 23:58 | <othermaciej> | jamesr___: yeah, I am not sure if event handlers, function timers, and miscellaneous functioncallbacks, are all meant to be handled by the post-task catchall |
| 23:58 | <othermaciej> | jamesr___: or if they should have some specific affordance |
| 23:58 | <jsbell> | jgraham: as far as chrome's test harness goes, https://localhost:8443 should be available |
| 23:59 | <othermaciej> | jamesr___: it potentially makes a difference, for example for events dispatched synchronously from within script |