| 10:36 | <annevk> | I don't really understand jQuery |
| 10:36 | <annevk> | $("div").replaceWith([$("div"), "<b>test</b>"]) |
| 10:37 | <annevk> | Gives you "<b>test</b>", loses the <div> somehow... |
| 10:37 | <Ms2ger> | window.$ = do_what_i_mean |
| 10:37 | <annevk> | If you remove ', "<b>test</b>"' however, the <div> stays... |
| 10:37 | <annevk> | Ms2ger: any ideas how to reply to that oldNode.replaceWith() edge case thread? |
| 10:38 | <Ms2ger> | I've ignored it |
| 10:39 | <annevk> | Ms2ger: that's not a great way to deal with feedback |
| 10:40 | <annevk> | Ms2ger: also, I think those algorithms might in fact have some issues |
| 10:40 | <Ms2ger> | That's your job :) |
| 11:13 | <zcorpan> | annevk: seems like a bug to remove the div there |
| 11:22 | <jgraham> | Anyone know if the reftest.list files in CSS are actually correct? |
| 11:28 | <jgraham> | Oh, they seem to be generated so I'll assume they are |
| 11:47 | <GuidoBouman> | Are Flexbox questions allowed here as well? ^_^ |
| 11:48 | <SimonSapin> | jgraham: correct how? |
| 11:58 | <annevk> | zcorpan_: should after() / before() / replaceWith() all work the same if you pass in the context object? |
| 11:59 | <annevk> | zcorpan_: suggestions welcome in that thread |
| 12:04 | <zcorpan_> | annevk: i think jquery ignores the context node when it appears in an array for after/before/replaceWith |
| 12:05 | <zcorpan_> | http://jsbin.com/cunejumepo/1/edit |
| 12:07 | <zcorpan_> | what is more valuable, consistency with insertBefore etc, or with jQuery, being easier to debug mistakes, addressing more use cases? |
| 12:24 | <jgraham> | SimonSapin: Correct in the sense of "not incorrect" :) |
| 12:24 | <jgraham> | e.g. if they were hand-written files that didn't get updated regularly |
| 12:24 | <SimonSapin> | I don’t know |
| 12:25 | <jgraham> | OK |
| 12:25 | <annevk> | zcorpan: speed and simplicity were some of the original requirements |
| 12:28 | <zcorpan> | annevk: ok. i think i'm the wrong person to have an opinion on what is better here |
| 12:59 | <JakeA> | annevk: I'm having to duplicate the about:blank handling from https://html.spec.whatwg.org/multipage/browsers.html#dom-open for cliens.openWindow() - is it appropiate to file a bug with the HTML spec asking for this to be abstracted? |
| 13:00 | <annevk> | JakeA: yeah, make it clear what you need though |
| 13:00 | <JakeA> | shall do |
| 13:00 | <JakeA> | cheers! |
| 13:42 | <annevk> | JakeA: did you see the bug I copied you on? |
| 13:43 | <annevk> | JakeA: I can't really figure out how to make service workers not observable... |
| 13:43 | <annevk> | JakeA: even ev.default() will have some effect (though it's unclear what that should be) |
| 13:44 | <JakeA> | annevk: which bug sorry? |
| 13:46 | <annevk> | JakeA: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27524 |
| 13:47 | <JakeA> | ta |
| 13:53 | <wanderview> | JakeA: annevk: if a document does a network request, triggers a SW fetch event, SW starts a different fetch() or cache.add().... and then the original document navigates away before the SW network requests finish... should those requests triggered from the SW fetch event be canceled or completed? |
| 13:54 | <annevk> | wanderview: I'm not sure what should happen to the FetchEvent instance, but the fetch() and cache.add() should succeed I would think |
| 13:54 | <annevk> | wanderview: we don't want to have to traverse the calling stack |
| 13:55 | <wanderview> | annevk: well, in gecko we have the concept of a "load group"... if we share the load group with the document, then they will get canceled... don't think we need to "traverse the calling stack", but maybe I don't understand what you mean |
| 13:55 | <wanderview> | right now we don't share the document load group directly with the service worker, though |
| 13:55 | <wanderview> | annevk: sorry, forgot to CC you on this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1122917 |
| 13:55 | <JakeA> | annevk: wanderview: I took a stab at this over in https://github.com/slightlyoff/ServiceWorker/issues/592#issuecomment-68853209 |
| 13:58 | <wanderview> | JakeA: I think that works... basically don't cancel the network request, but abort any resulting stream |
| 13:58 | <wanderview> | JakeA: and sorry... I read the later comments there, but somehow missed your comment |
| 13:59 | <JakeA> | wanderview: No worries! My comment was just a guess, but we don't really know if the request was associated with the fetch event until that point |
| 13:59 | <annevk> | wanderview: I don't like this "load group" concept as it's not part of any spec, but I guess we need to define something like it at some point |
| 13:59 | <wanderview> | JakeA: yea... since there can be multiple fetch events in flight at once... it seems we have to wait for resolveWith() |
| 14:00 | <annevk> | wanderview: but given a document A and a service worker SW, they should probably never share a load group, except maybe for "default" cases, where it is a bit unclear how those should work |
| 14:00 | <wanderview> | annevk: well... load group is a gecko implementation detail... doesn't have to be specifically in the spec... and its kind of hard to work with |
| 14:01 | <annevk> | wanderview: yeah, well we need a concept in specs of all fetches associated with a global |
| 14:01 | <annevk> | wanderview: for various reasons |
| 14:01 | <JakeA> | annevk: event.default() differs from fetch(event.request) in that it'll return redirects that'll be processed by the fetch spec without further SW interaction right? What does the synchronous part do? |
| 14:01 | <wanderview> | annevk: in the event.default() case... gecko treats the load as being performed by the document (with its load group), not the SW... |
| 14:02 | <wanderview> | synchronous part? |
| 14:02 | <annevk> | JakeA: see the last comment |
| 14:02 | <JakeA> | wanderview: sorry, crossing the streams a little, I'm talking about https://www.w3.org/Bugs/Public/show_bug.cgi?id=27524 |
| 14:03 | <annevk> | wanderview: that is sort of what the spec says for event.default() as well, however, what's unclear is how we deliver notifications to both globals |
| 14:04 | <wanderview> | annevk: I didn't realize the SW got any more events for that fetch event() once it did event.default()... or is that something we want to change? |
| 14:05 | <annevk> | wanderview: how does the SW get a Response object out of event.default() if not for some kind of queued task from the network layer? |
| 14:05 | <annevk> | wanderview: and how do we maintain progress updates to the document at the same time? |
| 14:05 | <JakeA> | Ohhh, I think I'm starting to understand |
| 14:06 | <annevk> | wanderview: seems like it would require a very special path |
| 14:06 | <wanderview> | annevk: ah... I missed that it does that! :-) for some reason I was thinking event.default() basically just sent it back to document... but I guess thats responseWith() using no argument |
| 14:07 | <wanderview> | or maybe I'm confused still |
| 14:08 | <JakeA> | annevk: What if event.default() called fetch in a way that would give it back redirects (opaque if needed), and they're sent back to the original fetch which handles the redirects and doesn't call back into the SW |
| 14:08 | <JakeA> | Is that observable? |
| 14:09 | <JakeA> | As far as I can remember event.default() was there pave over the redirect behaviour of a new fetch call consuming redirects |
| 14:10 | <wanderview> | I guess there is no respondWith()... you have to do event.respondWith(event.default()) |
| 14:10 | <annevk> | JakeA: yeah, download progress is still gone |
| 14:11 | <JakeA> | annevk: the response is passed back to the browser before the stream is read |
| 14:11 | <annevk> | JakeA: you might get the "progress" from sending it from SW to A, but the idea is that you get the progress from what actually happens network-wise (at least when using .default()) |
| 14:12 | <annevk> | JakeA: that is true |
| 14:12 | <wanderview> | annevk: I'm guessing on the impl side we can make the progress work... but not sure how it should be spec'd |
| 14:13 | <JakeA> | If progress is judged by content-length headers & the stream, doesn't it just work? |
| 14:13 | <annevk> | I doubt it "just" works :-) |
| 14:13 | <annevk> | For one thing there's that bug |
| 14:14 | <JakeA> | That's my specing style. 1. Just, make it happen. 2. Srs have you even started yet? 3. Return correct response. |
| 14:15 | <annevk> | heh |
| 14:16 | <JakeA> | annevk: If event.default() made a new fetch, which would return raw redirects, then pass those back to the original fetch, doesn't that get us out of having to go from fetchA to SW to fetchA and back to SW? |
| 14:16 | <wanderview> | annevk: in gecko we have the concept of a "network callback" which can be set on a load group to effect many requests, or just on a single network request... progress is communicated back to the document that way (I think)... so we can, in theory, set the progress callback for the document while performing the fetch in the SW context |
| 14:16 | <annevk> | So yeah, redirects were observable, anything else? |
| 14:17 | <annevk> | JakeA: then Fetch needs to know SW used default() |
| 14:18 | <annevk> | JakeA: see https://fetch.spec.whatwg.org/#http-fetch for how that would fall apart now |
| 14:18 | <JakeA> | annevk: I think that's just a side effect of using event.default(). Things don't change from the document's perspective though, as the redirects are handled by the original fetch, baseurls are fine |
| 14:18 | <JakeA> | annevk: Don't see how fetch needs to be aware of event.default(), although I've probably forgotten why |
| 14:19 | <annevk> | JakeA: if default() does not handle redirects you can't store it in the cache as easily anymore |
| 14:19 | <wanderview> | annevk: JakeA: sorry if this was discussed and I missed... but in the case where SW calls respondWith() with a different fetch() or cache.add()... should the document still get progress updates? is this unique to default()? |
| 14:20 | <annevk> | JakeA: also HTTP Fetch cannot block on all opaque stuff anymore and has to inspect if it's a redirect |
| 14:20 | <annevk> | wanderview: it's a bit unclear |
| 14:21 | <wanderview> | as a user... I imagine I would expect to still get progress in those cases |
| 14:21 | <annevk> | wanderview: and I think you do given that the progress is mostly about the stream anyway |
| 14:22 | <annevk> | wanderview: though you wouldn't if someone consumed the whole stream in the SW and then constructed a response and then passed that back |
| 14:22 | <wanderview> | annevk: so the terminology we use in our impl is that there is a "progress event sink"... can that be spec'd? so when event.respondWith(resp) is called, the UA sets the progress event sink for the associated document on the response? |
| 14:22 | <wanderview> | and event.default() starts with the documents progress event sink |
| 14:22 | <JakeA> | wanderview: the browser should use the response it gets via respondWith to determine progress. So event.respondWith(fetch(url)) would show progress, event.respondWith(fetch(url).then(r => r,text()).then(t => new Response(t))) wouldn't |
| 14:23 | <annevk> | Yeah, what JakeA says the specification defines now, that'd be hard to change |
| 14:23 | <annevk> | JakeA: I don't see a way around Fetch needing to know about default() |
| 14:23 | <wanderview> | ok, I think we have an impl bug... because I don't think we report progress in that case |
| 14:24 | wanderview | goes to bugzilla. |
| 14:24 | <annevk> | JakeA: and it knows about default(), you might as well follow all the redirects in SW... |
| 14:24 | <annevk> | JakeA: (so you can store the response in the cache) |
| 14:25 | <annevk> | wanderview: progress events are based on the stream that comes from the network; from the document's perspective, the network is the SW; from the SW, it's the actual network |
| 14:25 | <JakeA> | annevk: we talked about the SW being able to pass a response back that contained something to say "btw, treat the base url as [whatever]" to work around this |
| 14:25 | <JakeA> | I think it was dismissed as too hacky at the time |
| 14:25 | <JakeA> | but maybe it's simpler? |
| 14:25 | <annevk> | wanderview: the confusing bit here is that the stream is shared and at some point probably cloned so it can be read simultaneously |
| 14:25 | <wanderview> | annevk: yea... but our current impl does not report progress (afaict) for event.respondWith(fetch(url)) |
| 14:26 | <JakeA> | wanderview: fwiw, I don't Chrome does it with caches. Don't think those stream yet. |
| 14:26 | <annevk> | JakeA: so we'd annotate the response from a .default() somehow? |
| 14:27 | <annevk> | JakeA: as meaning "imagine you followed a redirect to get here" |
| 14:27 | <JakeA> | annevk: yeah |
| 14:27 | <annevk> | JakeA: it is pretty hacky |
| 14:27 | <JakeA> | :D |
| 14:27 | <JakeA> | less hacky than trying to loop back into the SW? |
| 14:28 | <annevk> | JakeA: the alternative is that you don't get anything out of a .default() |
| 14:28 | <annevk> | JakeA: that it's exactly identical to letting the request fly |
| 14:28 | <annevk> | JakeA: sorry, to not do anything with the event |
| 14:29 | <annevk> | JakeA: because now it is a bit different from not doing anything with the event, which is somewhat weird |
| 14:32 | <JakeA> | annevk: I think event.default().catch(getAFallbackFromCache) needed |
| 14:35 | <JakeA> | From memory, event.default() was there to let the browser do it's normal thing, but still offer recovery from failure. Caching result is nice too |
| 14:36 | <JakeA> | annevk: if event.default() resolves with the eventual response, it isn't *ideal* for caching as you'd be caching it against the original request url |
| 14:36 | <JakeA> | So your base urls would be off next time you get from the cache |
| 14:37 | <JakeA> | (unless it had Jake's patented super magic "use this as the base url" hack) |
| 14:42 | <wanderview> | JakeA: yea... the annoying thing is we don't get stuff like progress events for free with data streams in gecko... network streams are completely different than other streams :-\ |
| 14:43 | <annevk> | JakeA: should we instead drop default() and put a way to mutate a response into requiring a synthetic redirect? |
| 14:44 | <JakeA> | annevk: I'm very interested in that. I've been wanting to kill .default() forever. |
| 14:44 | <annevk> | JakeA: I know :-) |
| 14:45 | <annevk> | JakeA: open a ticket? |
| 14:45 | <JakeA> | Shall do |
| 15:05 | <JakeA> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/607 |
| 15:37 | <JakeA> | annevk: speccing Client. Multiple methods return a client object, but client doesn't have a constructor (although I guess it could), where would I define the construction steps? As in, taking an environment settings object and setting all the properties etc |
| 16:19 | <annevk> | JakeA: some prose |
| 16:19 | <annevk> | JakeA: "To /create a Client object/, run these steps:" |
| 16:23 | <JakeA> | annevk: Thanks. Also, I'm hitting the problem I think you tried to explain to me in the past. If the client is a SharedWorker, postMessage doesn't really fit, as SharedWorker doesn't have onmessage (it depends on ports for reasons I've never entirely understood). I guess this is why we should have WindowClient, but then just instances of DedicatedWorker & |
| 16:23 | <JakeA> | SharedWorker? |
| 16:57 | <JakeA> | Never understood way SharedWorker uses ports the way it does. Why can't it just be sharedWorker.postMessage(…), then the worker can respond via messageEvent.source |
| 16:57 | <JakeA> | why* |
| 16:58 | <caitp> | 0 |
| 16:59 | <Ms2ger> | Symmetry? |
| 16:59 | <JakeA> | Symmetry with what? |
| 17:03 | <jgraham> | Could be that it was designed with the idea that everyone would be passing around ports as part of some capabilties system, which might skew one's views on good api design |
| 17:16 | <annevk> | JakeA: wait, does client.postMessage() go to window.onmessage? |
| 17:16 | <annevk> | JakeA: or to navigator.serviceWorkers...? |
| 17:17 | <annevk> | JakeA: the way shared worker works is that each worker or document that connects to it gets its own port |
| 17:17 | <annevk> | JakeA: however, when a shared worker is controlled by a service worker we should not use that API |
| 17:17 | <annevk> | JakeA: because that is a completely different relationship |
| 17:18 | <Ms2ger> | annevk, I wonder if there's anything useful in https://github.com/operasoftware/presto-testo/tree/master/imported/peter/unicode/html |
| 17:19 | <JakeA> | annevk: client.postMessage would go to window.onmessage I thought |
| 17:19 | <annevk> | Ms2ger: double and ent look redundant |
| 17:19 | <annevk> | JakeA: ooooh, that's a lot of branching for window.onmessage then... |
| 17:20 | <annevk> | JakeA: I thought the events would go to the associated ServiceWorker object |
| 17:20 | <annevk> | Ms2ger: maybe the excess stuff but I suspect we already got that covered elsewhere too |
| 17:21 | <Ms2ger> | Ok, thanks for looking |
| 17:21 | <annevk> | JakeA: it seems pretty bad to overload window.onmessage like that |
| 17:22 | <JakeA> | annevk: navigator.serviceWorker.onmessage? We don't have that right now, but we could. What's the issue with window.onmessage? https://html.spec.whatwg.org/multipage/comms.html#dom-window-postmessage makes it look simple aside from the transferables |
| 17:22 | <annevk> | JakeA: it's already used for cross-window postMessage |
| 17:23 | <annevk> | JakeA: how can only client have postMessage()? How do you postMessage() from the window? |
| 17:24 | <JakeA> | annevk: I thought of window-to-window as client-to-client |
| 17:24 | <annevk> | JakeA: no, so ServiceWorker inherits from Worker |
| 17:24 | <annevk> | JakeA: and that has both postMessage() and onmessage |
| 17:25 | <annevk> | JakeA: Client is the other side |
| 17:25 | <annevk> | JakeA: it only makes sense for those two to talk to each other |
| 17:25 | <JakeA> | annevk: messageEvent.source.postMessage would post back to serviceWorkerGlobalScope.onmessage |
| 17:25 | JakeA | thinks |
| 17:28 | <JakeA> | annevk: so you were thinking the message would go to (await navigator.serviceWorker.getRegistration()).active? |
| 17:28 | <annevk> | yeah |
| 17:29 | <annevk> | that's the only thing that made sense to me and would work for both documents and workers |
| 17:29 | <annevk> | and would give a somewhat sane API |
| 17:29 | <annevk> | and be consistent with what we have for workers today |
| 17:29 | <annevk> | Are you now going to tell me that Chrome implemented something else? |
| 17:30 | <JakeA> | We haven't implemented clients yet |
| 17:30 | <annevk> | No messaging at all? |
| 17:31 | <JakeA> | Window to SW, but won't think we have a way back yet |
| 17:31 | <JakeA> | I think we need to stop & think about how this stuff works |
| 17:32 | <JakeA> | registration objects don't feel client-unique to me, so not sure they're a good place for onmessage either |
| 17:34 | <annevk> | I guess the only problem is that Client objects are currently designed as non-persistent |
| 17:34 | <annevk> | That doesn't make for a great message channel receiver |
| 17:35 | <annevk> | JakeA: I thought registration object was ServiceWorkerRegistration, not ServiceWorker |
| 17:35 | <annevk> | (I hate the naming) |
| 17:36 | <JakeA> | annevk: yes, so (await navigator.serviceWorker.getRegistration()) is a ServiceWorkerRegistration, then .active is a ServiceWorker |
| 17:38 | <JakeA> | ServiceWorkerRegistration is an origin-level thing rather than a client-specific thing, so getting client-specific message on it, or its properties feels wrong. |
| 17:38 | <JakeA> | Lemmie write up an issue \o/ |
| 17:40 | <annevk> | JakeA: well, it's the only way to get a reference to a a client's own service worker |
| 17:40 | <annevk> | JakeA: seems fairly fricking specific to me |
| 17:42 | <JakeA> | annevk: a client selects a registration, but many clients can select the same registration |
| 17:48 | <annevk> | JakeA: oh I see what you mean, I had imagined it would go to all of them, but indeed that does not really work |
| 17:48 | <annevk> | JakeA: okay, so yes, we need something new :/ |
| 17:49 | <JakeA> | annevk: I think postMessage & serviceWorker has been handwaved all the way :( |
| 17:50 | <JakeA> | annevk: It could be navigator.serviceWorker.onmessage for messages from a ServiceWorker. Anyway, will write up a ticket. Thanks for dragging me through it |
| 18:01 | <annevk> | JakeA: yeah, the whole "just like shared workers" stuff has been somewhat painful to point through |
| 18:01 | <annevk> | JakeA: thanks |
| 18:01 | <Ms2ger> | Do we still like shared workers? |
| 18:04 | <jgraham> | Pretty sure that the answer is "No" for all questions of the form "do we still like X" where X is a past web technology, and "Yes" where X is a future web technology |
| 18:12 | <caitp> | so you're saying there's a chance that opinions might change in 20 years? |
| 18:12 | <caitp> | goodness |
| 18:12 | <jgraham> | I'm saying that there's a discontinuity at t=present :p |
| 18:16 | <JakeA> | annevk: different subject, we're starting to look more seriously at background sync. I see FirefoxOS has something that I think was based on early ideas we had https://bugzilla.mozilla.org/show_bug.cgi?id=1018320 - who'd be best to get involved in making it a standard? |
| 18:16 | <annevk> | JakeA: it seems very likely it'll be the same people as service worker |
| 18:16 | <annevk> | JakeA: not sure we can get time from the Firefox OS folks |
| 18:17 | <JakeA> | annevk: ok, it'd be good to get their learnings, but I'll sort something out with Jonas & yourself |
| 18:18 | <annevk> | JakeA: copy overholt |
| 18:19 | <annevk> | JakeA: he'll know who to talk to |
| 18:19 | <JakeA> | Ta! |
| 18:25 | <JakeA> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/609 |
| 18:25 | <JakeA> | navigator.serviceWorker.onmessage seems to fit |
| 20:08 | <Domenic> | annevk: I managed to confuse myself about "queue a task" and microtasks and such again. What do you think would happen in the following? |
| 20:08 | <Domenic> | 1. Queue a task to: 1a. resolve the promise p; 1b. fire an event named "foo". Given that I've registered a fulfillment handler on p and a listener for "foo", which fires first? |
| 20:09 | <Ms2ger> | I think the listener |
| 20:09 | <Domenic> | At first I thought it'd be "foo" first since events are "synchronous". But then I thought it'd be p first since microtasks fire whenever you transition from UA code to user code. |
| 20:09 | <Domenic> | hmm |
| 20:09 | <Ms2ger> | But I have no idea how microtasks work |
| 20:10 | <Ms2ger> | Do they fire before calling event handlers? |
| 20:10 | <Ms2ger> | Presumably not, because then you could sniff whether there are event handlers attached for some type |
| 20:10 | <Domenic> | I ... think so. This might start falling into the unspecced areas :-/. Hixie do you know? |
| 20:19 | <Hixie> | Domenic: no microtasks would fire in that case until the first script for the first event listener returned, iirc |
| 20:20 | <Domenic> | Hixie: hmm OK. So saying "microtasks fire whenever transitioning from UA code to user code" is not really correct of me to say then. That's good to know. |
| 20:30 | <Hixie> | no it's much more specific than that |
| 21:39 | <annevk> | Domenic: the event goes first |
| 21:40 | <annevk> | Domenic: microtasks run end-of-task |
| 21:40 | <Domenic> | got it :) |
| 22:10 | <Ms2ger> | annevk, a few changes for you in https://critic.hoppipolla.co.uk/r/3723 |
| 22:44 | <Ms2ger> | zcorpan, fyi https://bugzilla.mozilla.org/show_bug.cgi?id=1122897 |
| 23:17 | <Hixie> | annevk: microtasks also run end-of-script |
| 23:17 | <Hixie> | annevk: are you sure they wouldn't run between two event listeners here? |
| 23:18 | <TabAtkins> | They should run between event listeners, I think. (I could easily be wrong.) |
| 23:38 | smaug____ | is missing the context, but if there isn't any other script on stack when event listeners run, microtasks run between them |
| 23:39 | <Hixie> | right |
| 23:40 | <Hixie> | in conclusion, Domenic, resolving the promise and then firing an event is going to lead to weird behaviour |
| 23:40 | <Domenic> | yep |
| 23:40 | <Hixie> | Domenic: you might be better off resolving then queueing a task to fire the event, or resolving then running microtasks then firing the event |
| 23:40 | <Hixie> | or not firing the event at all |
| 23:41 | <Domenic> | Yeah the current plan is actually just "when p fulfills, fire an event named 'foo'" |
| 23:41 | <Hixie> | is "fulfills" defined? |
| 23:41 | <Hixie> | like, what does that mean? |
| 23:43 | <Domenic> | http://www.w3.org/2001/tag/doc/promises-guide#shorthand-reacting |
| 23:50 | <Hixie> | i don't understand |
| 23:50 | <Hixie> | "fire an event" isn't a function |
| 23:51 | <Hixie> | you can't really define prose-given requirements in terms of javascript code |