| 01:06 | <karlcow> | http://engineering.flipboard.com/2015/02/mobile-web/ |
| 01:13 | <MikeSmith> | 60fps on the mobile Web, problem solved |
| 01:13 | <MikeSmith> | we'll just all use canvas! |
| 01:14 | <MikeSmith> | it's amazing that nobody's ever thought to do this before |
| 01:16 | <karlcow> | MikeSmith: they speak about Bespin in the article :) |
| 01:31 | <wanderview> | Accept is not a simple CORS header? but things like Accept-Language are? |
| 01:32 | <wanderview> | oh... nm |
| 08:20 | <zcorpan> | annevk: https://www.chromestatus.com/metrics/feature/timeline/popularity/465 looks like it's not declining particularly fast |
| 08:21 | <annevk> | zcorpan: yeah |
| 08:22 | <annevk> | zcorpan: still seems sane for browsers to warn about it though |
| 08:22 | <zcorpan> | maybe it's more effective to not talk about removing the feature but only talk about why using it is bad |
| 08:22 | <annevk> | zcorpan: e.g. the jQuery crowd started acting based on this I believe |
| 08:23 | <annevk> | zcorpan: and that latest thread was just ridiculous, someone arguing that you need synchronous fetching for scrolling... |
| 08:24 | <zcorpan> | yes |
| 08:27 | <Domenic> | I wonder if we could quarantine it to only pages that we already know are using it |
| 08:28 | <Domenic> | origins i guess would be the granularity boundary |
| 08:30 | <annevk> | Probably eTLD+1 given document.domain, but maybe |
| 08:35 | <annevk> | https://www.youtube.com/watch?v=PqHL9hKhX6I This <core-list> seems to be essentially what React is doing, just in a different way |
| 08:36 | <annevk> | So the argument that putting a lot of items in the DOM and rendering that quickly is impossible, is not disproven |
| 09:09 | <annevk> | philipj: you want to support promises from the prefixed version of the Fullscreen API? |
| 09:09 | <philipj> | annevk: no |
| 09:09 | <philipj> | did I write a terrible typ? |
| 09:11 | <philipj> | so, it would probably not be hard to support it for the prefixed APIs, I'm just not sure what the point would be |
| 09:11 | <philipj> | if shipped together with the unprefixed API, people who adapt to use promises should also stop using the prefixed API |
| 09:13 | <philipj> | annevk: I have "Read Fullscreen mail" on this weeks todo list, if the sudden interest in all things fullscreen seems out of characters |
| 09:14 | <annevk> | philipj: it sounded like you wanted to add promises before the unprefixed version was shipped |
| 09:14 | <annevk> | philipj: but perhaps you just meant added to the specification, which seems fine |
| 09:14 | <annevk> | philipj: like you I have taken a Fullscreen break |
| 09:15 | <annevk> | philipj: I still need to look at Hixie's changes to the event loop to allow for synchronization with animation frames |
| 09:15 | <annevk> | philipj: also, I guess we need to decide whether the promise needs to reject or return false or some such |
| 09:16 | <philipj> | annevk: I mean to the spec, and to only return the promises from the unprefixed API, by whatever implementation strategy is required to make it so |
| 09:16 | <philipj> | since it's a return value I think it's easy to just not update the prefixed IDL |
| 09:17 | <philipj> | annevk: you mean when the fullscreen ready check fails? |
| 09:21 | <annevk> | philipj: yeah |
| 09:23 | <annevk> | Okay, so the callback from HTML is "run the fullscreen rendering steps" and a timestamp |
| 09:23 | <annevk> | philipj: do you know what Fullscreen would use the timestamp for? |
| 09:24 | <philipj> | annevk: no idea, that sounds odd |
| 09:25 | <annevk> | https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9 step 8.8 |
| 09:40 | <JakeA> | annevk: re BackgroundSync ux: my current thinking is that one-off syncs should create some kind of sticky notification saying "Waiting to sync" or similar until the sync successfully completes |
| 09:40 | <JakeA> | No idea what to do with periodic syncing though |
| 09:41 | <annevk> | JakeA: where would that display? |
| 09:52 | <JakeA> | annevk: on Android, same place as native notifications |
| 09:52 | <annevk> | JakeA: is one-off a thing that native applications get too? |
| 09:53 | annevk | only remembers periodic background update UX |
| 09:54 | <philipj> | annevk: it sure looks like it's just passed for good measure, in case it's needed |
| 09:56 | <annevk> | philipj: the weird thing about Hixie's setup is that I can't queue some set of steps for this callback |
| 09:56 | <annevk> | philipj: I'd imagine there being some slot that has the set of actions that needs to be performed |
| 09:57 | <annevk> | philipj: but perhaps we need to define that ourselves as it's different for all the different cases? |
| 09:57 | <philipj> | annevk: can't you do whatever you want in "the fullscreen rendering steps"? |
| 09:57 | <annevk> | philipj: yeah I can |
| 09:58 | <annevk> | philipj: it's just that the whole task queueing model surrounding it does a lot more for you, but I guess that's oaky |
| 09:58 | <annevk> | okay* |
| 09:58 | <philipj> | I had imagined that there would be a generic bucket called "run the animation frame tasks" right before the callbacks, and that it would be possible to queue such tasks |
| 10:00 | <philipj> | if this spec is implemented quite literally it seems like a bit of an odd polling model |
| 10:03 | <JakeA> | annevk: https://developer.android.com/reference/android/app/AlarmManager.html see set(). That doesn't seem to deal with connectivity though |
| 10:04 | <annevk> | philipj: well it's something like that, except without the generic bucket |
| 10:04 | <annevk> | philipj: presumably so that all these things happen in the correct order? |
| 10:05 | <philipj> | annevk: I guess, although a task queue also has an order same as regular tasks really |
| 10:05 | <annevk> | JakeA: yeah, it seems you have wake-on-time, wake-on-network, wake-periodic-on-network, wake-on-times |
| 10:06 | <philipj> | If some of these steps (like resize/scroll) can influence later steps then fixinf the order is reasonable |
| 10:06 | <annevk> | philipj: so I'd imagine we have a slot on the global and then make HTML's callback run the code in that slot |
| 10:06 | <JakeA> | annevk: I don't see network stuff there |
| 10:06 | <annevk> | philipj: which is effectively the same as queuing a task except having it run at a specific time |
| 10:07 | <annevk> | JakeA: sorry, was combining that with what we have |
| 10:07 | <annevk> | JakeA: as use cases |
| 10:07 | <JakeA> | ahh gotcha |
| 10:07 | <JakeA> | yeah |
| 10:07 | <annevk> | iOS has "Background App Refresh" |
| 10:07 | <JakeA> | Seems that Android makes wake-when-reconnected quite difficult http://stackoverflow.com/questions/15698790/broadcast-receiver-for-checking-internet-connection-in-android-app |
| 10:08 | <philipj> | annevk: I guess your rendering steps are going to do nothing at all most of the time? |
| 10:08 | <annevk> | I think alarm/calendaring is probably related to the "notifications" permission |
| 10:08 | <philipj> | just see if there's a pending task and if so run it? |
| 10:08 | <annevk> | philipj: yeah, I would expect the slot to be empty mostly |
| 10:09 | <annevk> | philipj: that's why I kinda wish Hixie had formalized the slot idea, perhaps I should ask |
| 10:09 | <philipj> | yeah, probably should |
| 10:09 | <philipj> | also, the name "run the fullscreen rendering steps" probably won't make sense |
| 10:09 | <philipj> | nothing is being rendered, it's just events being fired and state being twiddled |
| 10:11 | <annevk> | philipj: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28001 |
| 10:13 | <annevk> | JakeA: perhaps the UX should just be asking for "background updates" |
| 10:13 | <annevk> | JakeA: and if you have given both "notification" and "background updates" you can get alarms |
| 10:14 | <JakeA> | annevk: on Chrome, I believe we roll background & notification into one permission prompt (for push anyway) |
| 10:15 | <annevk> | I remember not liking what I heard about push and Chrome |
| 10:15 | <annevk> | but I don't really recall the specifics |
| 10:15 | <philipj> | annevk: thanks |
| 10:40 | <JakeA> | annevk: there's a bit of magic at the moment as we ease ourselves into the idea of sites running code in the background |
| 10:41 | <JakeA> | annevk: specifically, a push event must show a notification unless the site has focus |
| 10:41 | <annevk> | JakeA: I'm not sure that's true |
| 10:41 | <annevk> | JakeA: if I granted a site the permission to do work in the background, I don't think a notification would need to be shown |
| 10:42 | <JakeA> | annevk: yeah, but there's a lot of (justified imo) worry around privacy issues |
| 10:43 | <JakeA> | So we want users to be aware that a site did background work |
| 10:43 | <JakeA> | As it can be used to track location at an IP level |
| 10:44 | <JakeA> | The hope is to relax this as we work out the UX and user sentiment |
| 10:45 | <annevk> | I definitely support making it discoverable and easy to disable, etc. But prominent UI whereas native gets away with a better experience does not seem acceptable |
| 10:46 | <annevk> | So yeah, that was the thing that irked me about Chrome and push |
| 10:46 | <annevk> | I think mt is handling that mostly from Mozilla, but maybe I should verify that |
| 11:03 | <annevk> | Hmm... CORS filtered response does not filter out Set-Cookie and Set-Cookie2 at all times, oops |
| 11:11 | <annevk> | Fixed |
| 11:15 | <JakeA> | annevk: once we have a better way to ensure the user knows what's able to run in the background, that restriction will be lifted |
| 11:16 | <annevk> | I think what was bothering mt was that it was influencing API design |
| 11:16 | <JakeA> | annevk: the big worry is users that are tricked into accepting push for something friendly, but it abusing that without the user knowing |
| 11:23 | <annevk> | Yeah it's definitely a tricky concept |
| 11:24 | <annevk> | But I think the problem was that it got to point where Google UX decisions started to influence the API in a way that didn't work for others |
| 11:25 | <annevk> | Need to check with mt what the latest is |
| 11:27 | <JakeA> | annevk: I'm not aware of API changes that have resulted from this privacy caution |
| 11:28 | <JakeA> | annevk: the only privacy API change I'm aware of is the requirement to encrypt the push body so the message server can't read it. I think that came mainly from Mozilla |
| 11:28 | <annevk> | JakeA: that's the protocol, no? |
| 11:28 | <annevk> | JakeA: that sounds like a good change |
| 11:29 | <JakeA> | annevk: it's not the protocol, tls is already required for data transfer |
| 11:32 | <JakeA> | annevk: the requirement is, when you register for push, the reg object gives you a key & an encryption format, which you send to your server. Before your server sends a message to the messaging-service, you encrypt the body using that format & key. |
| 11:33 | <JakeA> | The messaging-service sends it to the phone, which it decrypts |
| 11:34 | <JakeA> | So the messaging service doesn't get to see the body of the push |
| 11:34 | <JakeA> | Pretty cool, but really complicates usage & API |
| 11:36 | <annevk> | I wonder if that could have been done in a simpler way by making use of TLS which is already in place, but I guess people tried to think of that already |
| 11:37 | <JakeA> | annevk: if you can think of a simpler way, it's still up for debate. We're shipping without message bodies in the meantime. |
| 11:37 | <JakeA> | I can't think of a way, but my crypto knowledge is weak |
| 11:40 | <annevk> | It seems like you need something like this |
| 11:41 | <annevk> | JakeA: so what parts will the intermediary learn? Just the origin involved? |
| 11:42 | <JakeA> | annevk: it'll know the sender & obviously the time of each message |
| 11:43 | <annevk> | JakeA: yeah, seems hard to avoid |
| 11:43 | <JakeA> | Oh course, if push bodies were unencrypted, there's nothing preventing a site adding their own encryption |
| 11:43 | <JakeA> | But forcing it seems sensible when the browser/os/messaging service aren't all the same provider |
| 11:44 | <annevk> | Yeah, but as we learned from HTTP, optional is not good long term |
| 11:45 | <JakeA> | annevk: btw, haven't managed to get hold of Hixie, are you up for a call on SW & postMessage tomorrow evening? |
| 11:45 | <annevk> | JakeA: the API draft doesn't seem to include this encryption stuff yet |
| 11:46 | <JakeA> | annevk: yeah, it's still being debated, although I'm not sure where exactly (but I know Mozilla is involved) |
| 11:47 | <annevk> | JakeA: I feel like I haven't been involved enough in the development of the various postMessage schemes to know what we should be doing |
| 11:48 | <JakeA> | For the postMesage stuff, I'm still circling on clients receiving messages at navigator.serviceWorker.onmessage, and serviceworker receiving them at self.onmessage. It breaks some of the symmetry, but it's easy to use and doesn't break existing APIs |
| 11:48 | <JakeA> | annevk: if not Hixie, who has enough of this stuff in their head? |
| 11:48 | <annevk> | JakeA: maybe smaug____ |
| 11:49 | <JakeA> | smaug____: what say you to some form of synchronous communication to help us get unstuck on ServiceWorker & postMessage? |
| 11:50 | <JakeA> | (and what timezome are you in?) |
| 11:50 | <annevk> | JakeA: so the idea is navigator.serviceWorker.onmessage/navigator.serviceWorker.postMessage and self.onmessage/client.postMessage on the other side? |
| 11:50 | smaug____ | lives in smaug-timezone as someone put it couple of years ago |
| 11:50 | <smaug____> | JakeA: I live in Helsinki, so EET |
| 11:50 | <annevk> | JakeA+2h |
| 11:51 | <smaug____> | sync communication ? |
| 11:52 | <JakeA> | smaug____: a video/voice call |
| 11:53 | <JakeA> | annevk: swClient.postMessage would land at navgiator.serviceWorker.onmessage, navigator.serviceWorker,controller.postMessage would land at self.onmessage |
| 11:53 | <annevk> | JakeA: I think that if we try to explain this in terms of message channels (which I think we need in order for this to work) we might get somewhere |
| 11:54 | <smaug____> | JakeA: eh, I thought you were talking about synchronous communication API |
| 11:54 | <smaug____> | apparently no |
| 11:55 | <JakeA> | annevk: I guess it could be navigator.serviceWorker.controller.onmessage, but I was hoping there'd be a way for a client to listen for messages from *any* SW, rather than having to add onmessage to each and monitor for new SWs appearing & listen to those too |
| 11:55 | smaug____ | has no idea what the issue is |
| 11:55 | <JakeA> | smaug____: we're trying to work out how a serviceworker could send a message to a specific client on the same origin |
| 11:56 | <annevk> | JakeA: that is why you need to look into message channels and how you explain the underlying functionality |
| 11:56 | <JakeA> | where a client is a window/worker/sharedworker |
| 11:56 | <JakeA> | annevk: yeah, that's fair |
| 11:56 | <annevk> | JakeA: currently you're just trying to invent some sugar without understanding what it comes down to |
| 11:57 | <JakeA> | annevk: yeah, I guess I'm trying to avoid ending up with a semantically pure but virtually impossible to use API. But I should at least be able to explain it in terms of the channel stuff. |
| 12:01 | <smaug____> | I don't think I know enough about the issue to say anything useful. I'd try to follow the SharedWorker model if possible, but perhaps there is some reason why that doesn't work here |
| 12:04 | <annevk> | So the main problem with SW is that it can come and go. So its port can get GC'd at any point but we don't really want to lose any messages I think... |
| 12:04 | <annevk> | So you need some kind of intermediary place where the messages go first. And then whenever an SW boots up they get transmitted until the SW shuts down again. |
| 12:04 | <JakeA> | smaug____: The browser may terminate the serviceworker while it isn't being used to save memory, so the sharedworker model of connect events & keeping posts in scope doesn't work. Also, in the sharedworker model the client must explicitly connect to the sharedworker before the sharedworker can contact the client. I'm hoping the serviceworker can send |
| 12:04 | <JakeA> | messages to specific clients, and all the client has to do to receive them is register an onmessage event somewhere |
| 12:05 | <annevk> | JakeA: what if the client instead registers an onserviceworkerconnect handler? |
| 12:05 | <annevk> | JakeA: and gets handed a port there |
| 12:06 | <JakeA> | annevk: when would that fire? |
| 12:06 | <annevk> | But yeah, then you have the opposite problem, how to send to the SW |
| 12:07 | <JakeA> | annevk: I think that problem is solved right? serviceWorkerInstance.postMessage to self.onmessage doesn't feel controversial. |
| 12:07 | <JakeA> | although I guess there's a reason sharedworker doesn't have something that simple |
| 12:07 | <annevk> | JakeA: that is controversial since you can't explain it in terms of ports |
| 12:07 | <annevk> | JakeA: so I have no idea how it works, exactly |
| 12:08 | <JakeA> | hm |
| 12:08 | <annevk> | Perhaps something like BroadcastChannel but specific to this scenario? |
| 12:09 | <JakeA> | that model feels like a better fit, but directed at a specific client. It'd be great if it could reuse broadcastChannel fundamentals because Chrome could implement both |
| 12:10 | <annevk> | So BroadcastChannel could work if you have some identifier unique to the client... |
| 12:11 | <annevk> | JakeA: I can talk tomorrow night, but I rather not, and also earlier the better |
| 12:11 | <JakeA> | annevk: are you suggesting that the developer has to filter out the messages or that the spec does that? |
| 12:12 | <annevk> | JakeA: hmm lunch |
| 12:12 | <annevk> | JakeA: my idea was we give the dev some identifier for BroadcastChannel (perhaps through a sublcass) so they get one unique for a particular client |
| 12:12 | <annevk> | back later |
| 12:13 | <JakeA> | have a good'un. I really should be writing a talk :( |
| 12:44 | <jgraham> | I think "this is all horrible, but that's life" is my new motto |
| 12:57 | <annevk> | jgraham: fits you well :-) |
| 12:57 | <annevk> | That was a rather fun email to read |
| 13:00 | <annevk> | JakeA: so here is an idea |
| 13:01 | <annevk> | JakeA: the document/worker creates a ServiceWorkerChannel |
| 13:01 | <annevk> | JakeA: in the service worker we expose some kind of uuid per client |
| 13:01 | <annevk> | JakeA: then you construct a ClientChannel by passing it that uuid |
| 13:01 | <annevk> | JakeA: and then they entangle and things work |
| 13:02 | <annevk> | JakeA: we could not even expose a uuid and instead just use the Client objects as parameter, keeping the identification hidden |
| 13:03 | <annevk> | JakeA: it has the fancy pansy constructor design to please Domenic and seems easy enough to use |
| 13:03 | <annevk> | JakeA: if the SW of a document/worker changes existing ServiceWorkerChannel objects will just get associated anew |
| 13:04 | <JakeA> | annevk: can a single ServiceWorkerChannel get messages from multiple serviceworkers? |
| 13:05 | <annevk> | JakeA: over time |
| 13:05 | <JakeA> | or is it one per sw |
| 13:05 | <JakeA> | cool |
| 13:05 | <annevk> | JakeA: it's associated with the SW that's associated with the document |
| 13:05 | <JakeA> | So I can get messages from my active worker, an installing worker, and even workers from another scope? |
| 13:05 | <JakeA> | ohh, so I can't get messages from an installing worker |
| 13:06 | <annevk> | we could generalize the design on both sides |
| 13:06 | <annevk> | if you pass it a specific worker/client it can only communicate with that worker/client, otherwise all of them? |
| 13:07 | <annevk> | however, note that with some clever naming scheme this should be doable on top of BroadcastChannel as well... |
| 13:09 | <annevk> | using the client's url as identifier + adding the type of SW (active, installing, any), or leaving them out if you want a more generic BroadcastChannel |
| 13:09 | <annevk> | so perhaps BroadcastChannel + library is a better way to go |
| 13:11 | <JakeA> | annevk: if the SW has terminated, how does it get broadcastchannel messages? |
| 13:12 | <annevk> | ah right, that's why we need something special |
| 13:12 | <annevk> | document/worker -> magic -> service worker |
| 13:13 | <annevk> | so yeah, for that primitive we need something very much like BroadcastChannel but with the background queueing |
| 13:14 | <annevk> | so perhaps ServiceWorkerChannel(optional name) for document/worker and ClientChannel(optional name) for service worker |
| 13:14 | <JakeA> | annevk: maybe the idea of stashed ports is useful here https://gist.github.com/mkruisselbrink/536632fcd99d45005064 |
| 13:20 | <annevk> | JakeA: so I'm trying to imagine the flow of that... |
| 13:20 | <JakeA> | annevk: I think this can be done better in similar terms to broadcastchannel |
| 13:20 | <annevk> | JakeA: C connects, SW gets handed a port, stashes port, gets shutdown |
| 13:21 | <annevk> | JakeA: C posts message, SW is booted, gets C connect event with new port?, gets message about stashed port? |
| 13:22 | <annevk> | JakeA: yeah, perhaps we should call it ServiceWorkerChannel on both sides, for the browser it's clear from context what's supposed to happen anyway |
| 13:22 | <JakeA> | annevk: C connects, SW gets handed a port, stashes port, gets shutdown. C posts message, SW is booted, SW gets self.onportmessage with the port & message |
| 13:23 | <JakeA> | annevk: but I still think there's a simpler model |
| 13:23 | <annevk> | JakeA: so if the port is stashed you would not get a connection event but a different one? |
| 13:24 | <annevk> | JakeA: it seems nicer if each time you just run the same code (create a ServiceWorkerChannel) |
| 13:25 | <JakeA> | annevk: In the stashed model, you don't need a connect event |
| 13:25 | <annevk> | JakeA: how do you get handed the port? |
| 13:26 | <JakeA> | annevk: in the onportmessage event? It's transferred from the stash |
| 13:26 | <annevk> | JakeA: so why do you need to retrieve it from the stash? |
| 13:26 | <annevk> | JakeA: seems like you should be able to store and delete them |
| 13:27 | <JakeA> | annevk: yeah, you'd need an AsyncPortCollection |
| 13:27 | <annevk> | JakeA: I do like this idea as it gives you the entire MessagePort ecosystem |
| 13:27 | <JakeA> | annevk: I think I dislike it for that reason :D |
| 13:27 | <annevk> | JakeA: everything that people build on top of ports can then automatically be ported to service workers |
| 13:28 | <annevk> | JakeA: so yeah, PortCollection has these problems: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23412 |
| 13:29 | <JakeA> | annevk: also, it doesn't give a way for the SW to contact a particular client. You'd have a collection of ports sure, but it isn't clear which is which |
| 13:29 | <annevk> | JakeA: however, PortStorage or some such doesn't really have the same issues I think |
| 13:29 | <annevk> | JakeA: we'd put the ports on the client objects and make the client objects live |
| 13:29 | <annevk> | JakeA: or some such |
| 13:29 | <JakeA> | annevk: yeah, not only that, but if you stash two entangled ports you've got a leak |
| 13:30 | <annevk> | JakeA: that could throw |
| 13:30 | <annevk> | Yeah I guess you want to store more than just the port, you need some metadata |
| 13:32 | <annevk> | I both like and dislike that this is a hard problem |
| 13:34 | <annevk> | JakeA: so say in clients ServiceWorker objects are live and in service workers Client objects are life, and both of them expose ports |
| 13:35 | <JakeA> | annevk: I'd still like this to be more under-the-hood. Say when a new page/worker is created, it creates a port pair. When the SW gets a client object, client.postMessage goes to port2.postMessage. port1.onmessage proxies to navigator.serviceWorker.onmessage. You could call it onserviceworkermessage is the naming is a problem (since many ports would land |
| 13:35 | <JakeA> | messages there) |
| 13:35 | <annevk> | JakeA: if you want for a particular port to remain active from the point of the service worker you store it, and then you remove it once you no longer care |
| 13:35 | <annevk> | JakeA: once clients are GC'd the corresponding ports in storage can also be GC'd |
| 13:36 | <annevk> | JakeA: I think that would work |
| 13:37 | <annevk> | JakeA: that doesn't really solve any of the persistency problems, that's sugar we could add later |
| 13:37 | <annevk> | (with "I think that would work" I was referring to my proposal) |
| 13:38 | <JakeA> | annevk: so, self.clients.getAll().then(c => c[0]) - c[0] has a .port? |
| 13:39 | <annevk> | JakeA: if clients become live, I would expect self.clients[0] or some such to work |
| 13:39 | <annevk> | JakeA: and yes, it would |
| 13:40 | <annevk> | JakeA: but unless you store it, it'll go dead |
| 13:41 | <JakeA> | annevk: why do they need to be live? (I'm worried about the overhead of updating those live) |
| 13:42 | <annevk> | JakeA: because the ports are live and it would be kind of weird for static objects to point to live ports that need to be === identical |
| 13:44 | <JakeA> | annevk: so where would client.port.postMessage land? |
| 13:45 | <annevk> | JakeA: navigator.serviceWorker.x.onmessage |
| 13:46 | <JakeA> | annevk: where x is a SW instance? So navigator.serviceWorker.controller.onmessage? |
| 13:47 | <annevk> | JakeA: yeah |
| 13:48 | <annevk> | perhaps the ServiceWorkerChannel idea is not that bad as this does seem rather horrid |
| 13:48 | <annevk> | and then have port stashing as a separate feature |
| 13:49 | <JakeA> | I think we've happened upon the hardest problem in computer science |
| 13:50 | <JakeA> | annevk: but if there's a way for multiple client ports to post message to serviceWorker.onmessage, I think we're getting close to a solution |
| 13:51 | <annevk> | no, ports are 1:1 |
| 13:51 | <JakeA> | annevk: if the stashing is under-the-hood, does client.postMessage work? |
| 13:51 | <JakeA> | hm I'm confused |
| 13:51 | <annevk> | something like BroadcastChannel can be N:N |
| 13:52 | <JakeA> | annevk: I thought you just said clients[0].postMessage and clients[1].postMessage land at navigator.serviceWorker.controller.onmessage |
| 13:54 | <annevk> | JakeA: yeah, but those would be distinct channels |
| 13:54 | <annevk> | JakeA: one for each client |
| 13:54 | <JakeA> | annevk: and something underneath proxies them to the single controller.onmessage? |
| 14:02 | <annevk> | I don't know, which is why I suggested that maybe ports were not the best idea and something like BroadcastChannel would be better |
| 14:04 | <caitp-> | how many SW do you anticipate living together and coordinating together? |
| 14:08 | <JakeA> | annevk: So if each page/worker created a BroadcastChannel using a unique id, client.postMessage could broadcast to that channel, navigator.serviceWorker.onmessage could receive it. The ServiceWorker could also create a uid BroadCastchannel to explain how serviceWorkerInstance.postMessage works. The trouble is identifying the source of those messages. Ideally |
| 14:08 | <JakeA> | the page wants to get an instance of the SW with the message, and the SW needs a client instance |
| 14:09 | <JakeA> | caitp-: serviceworker-to-serviceworker is being looked at by http://mkruisselbrink.github.io/navigator-connect/ - I don't really know a whole lot about it though |
| 14:10 | <caitp-> | my understanding was that they're sort of expensive, so a single application probably doesn't need to set up a whole bunch of them |
| 14:10 | <caitp-> | unless the idea is that the facebook api needs their own background thread or something, and all of your different tabs need to talk to it |
| 14:10 | <JakeA> | caitp-: that's more of a sharedworker thing I think |
| 14:11 | <JakeA> | A serviceworker registration can have 3 serviceworkers active at once, but that's pretty rare. Usually it's only 1. |
| 14:12 | <JakeA> | The three are installing (setting itself up to be the next version), waiting (ready to be the next version, but the current version is still in use), and active (the current version) |
| 14:14 | <JakeA> | The installing one would be running, as it's setting up caches and such. The waiting version is rarely running, although I guess it'd have to wake up if you did a postMessage to it. The active version wakes up when it needs to receive events, such as fetch, push, message etc |
| 14:17 | <annevk> | JakeA: why are you so attached to an existing API? |
| 14:18 | <annevk> | JakeA: if we have something like BroadcastChannel that works for service workers, why not let developers create the abstractions? |
| 14:23 | <JakeA> | annevk: maybe I'm letting existing things get in the way, but I don't want something more complicated than client[method-to-send-a-message](obj) + window.somewhere.addEventListener('receive-the-message', event => event[way-to-id-the-sender-and-post-a-message-back]) + serviceWorkerInstance[method-to-send-a-message] + |
| 14:23 | <JakeA> | self.addEventListener('receive-the-message', event => event[way-to-id-the-sender-and-post-a-message-back]) |
| 14:23 | <annevk> | what exists? |
| 14:24 | <annevk> | we already shipped something? |
| 14:24 | <annevk> | :-( |
| 14:24 | <JakeA> | huh? |
| 14:24 | <annevk> | "letting existing things get in the way" |
| 14:24 | <JakeA> | You brought up the existing bit. "why are you so attached to an existing API?" |
| 14:25 | <annevk> | Ah yeah, it seems like you have some idea what you want and try to layer anything on top of that idea |
| 14:25 | <annevk> | I'd be much more interested in just exposing the primitives that make messaging possible |
| 14:26 | <annevk> | It seems like we keep realizing that we're bad at API design so we should let developers do it and just expose the bare minimum, but then we don't really do that... |
| 14:26 | <JakeA> | I'm all for exposing primitives but only if it offers something useful & not just overcomplicating |
| 14:27 | <annevk> | If it's a primitive it's by definition not complex |
| 14:28 | <wanderview> | annevk: am I reading the fetch spec correctly in that Access-Control-Allow-Headers is required? https://fetch.spec.whatwg.org/#cors-preflight-fetch |
| 14:28 | <wanderview> | I don't see flickr returning that header... but it seem our fetch() calls go through |
| 14:28 | <annevk> | wanderview: that's only used for preflights |
| 14:28 | <JakeA> | An API to allow a serviceworker to message a specific client, and allowing a client to message a specific serviceworker doesn't sound like high-level luxury |
| 14:28 | <annevk> | wanderview: and only if custom headers are specified |
| 14:29 | <wanderview> | annevk: trained-to-thrill uses custom headers... passes an x-cache header or something |
| 14:29 | <JakeA> | wanderview: those never go to fetch() |
| 14:29 | <JakeA> | The SW stops requests with that header and never passes them to fetch |
| 14:29 | <wanderview> | JakeA: I thought I saw it in my network panel last night... I could have been dreaming, though |
| 14:30 | <gsnedders> | is there telemetry anywhere for what charset decoders are being used in browsers? |
| 14:30 | <JakeA> | wanderview: https://github.com/jakearchibald/trained-to-thrill/blob/master/www/static/js-unmin/sw/index.js#L61 |
| 14:31 | <annevk> | JakeA: it is a luxury if you add some kind of weird duplication/distribution thing to the mix, rather than keep it 1:1 |
| 14:31 | <wanderview> | JakeA: oh... I think I saw it in the case where SWs weren't enabled... so a fetch() is not done in that case |
| 14:31 | <JakeA> | wanderview: 'accept' is a simple header anyway, so won't trigger preflight |
| 14:31 | <wanderview> | yea |
| 14:31 | <annevk> | JakeA: the alternative is something like BroadcastChannel with optional scoping |
| 14:32 | <JakeA> | wanderview: requests with that 'accept' should only be sent if the page is controlled https://github.com/jakearchibald/trained-to-thrill/blob/master/www/static/js-unmin/index.js#L68 |
| 14:33 | <gsnedders> | AFAICT, Mozilla doesn't have any telemetry for that, and I get confused looked for stuff in the Google telemetry |
| 14:33 | <wanderview> | JakeA: hmm... I probably did something stupid :-) |
| 14:39 | <annevk> | JakeA: given that both sides have to cooperate I don't really see the problem with using SWC |
| 14:39 | <annevk> | JakeA: e.g. new SWC(url + swType) on both sides gives you quite specific control |
| 14:40 | <annevk> | JakeA: you can basically scope the messaging in any way you want, rather than being tied to some specific scenarios we cooked up |
| 14:41 | <gsnedders> | hswolff: I presume the DECODER_INITIATED was the best you could do, and actually having what encoding a given page is would be too expensive and too much data? |
| 14:51 | <JakeA> | annevk: dumped some requirements at https://github.com/slightlyoff/ServiceWorker/issues/609#issuecomment-74080640 |
| 14:52 | <gsnedders> | hswolff: sorry, wrong nick! |
| 14:53 | <JakeA> | annevk: what is swType? |
| 15:07 | <annevk> | JakeA: e.g. "installing" "active" |
| 15:07 | <JakeA> | annevk: hmm, so messages get lost if the sw changes state during a conversation? |
| 15:08 | <annevk> | JakeA: that depends on the conventions of your messaging strategy |
| 15:08 | <annevk> | JakeA: the argument is simply a string |
| 15:08 | <annevk> | JakeA: it's up to developers to decide what granularity they need |
| 15:11 | <annevk> | Thinking about it some more it's not entirely clear how waking up the service worker would work in a clean way with this proposal |
| 15:13 | <annevk> | JakeA: so yeah, maybe I'm coming around to the weird design |
| 15:14 | <annevk> | navigator.serviceWorker.onmessage / navigator.serviceWorker[x].postMessage() vs self.onmessage / self.clients.getClients().then((c) => c[0].postMessage()) |
| 15:14 | <JakeA> | annevk: you'd still need a way to stash/register the channel, and it'd need to be per serviceworker rather than per registration, so different to where push registrations are stored |
| 15:15 | <JakeA> | where event.source is the sending client/serviceworker? |
| 15:16 | <annevk> | It's not exactly pretty, and I've no idea what the underlying primitives are, but it could be written out in a way that would work |
| 15:16 | <annevk> | JakeA: a static copy of it I guess? |
| 15:16 | <annevk> | JakeA: would not === |
| 15:18 | <annevk> | JakeA: will try to think about it some more :/ |
| 15:18 | <JakeA> | annevk: !== is already true of clients and SerivceWorker instances. Clients are already static. ServiceWorker instances are live as they have .status and a statuschange event |
| 15:20 | <JakeA> | "!== is already true" urm, by that I mean they're not equal, even if they represent the same SW/client |
| 15:27 | <annevk> | JakeA: hmm, it seems weird if serviceworker instances are live that !== would be true |
| 15:27 | <annevk> | JakeA: is the spec broadcasting these statuschange events to all copies or some such? |
| 15:28 | <JakeA> | annevk: yeah |
| 15:29 | <annevk> | it's not exactly live if there's a bunch of copies |
| 15:29 | <annevk> | live is what the DOM is like |
| 15:29 | <JakeA> | annevk: === means making expandos work across window objects :( |
| 15:29 | <annevk> | e.g. <a> being only a single instance ever |
| 15:29 | <annevk> | JakeA: uhm you'd create one per window obv |
| 15:30 | <annevk> | JakeA: otherwise prototype would already be weird |
| 15:31 | <JakeA> | annevk: actually, === is probably useful in this case. if (messageEvent.source === navigator.serviceWorker.controller) |
| 15:31 | <annevk> | uhuh, also in the other case though |
| 15:31 | <annevk> | you kind of want live Client / SW objects |
| 15:35 | <JakeA> | Yeah, there is a lack of consistency there. Live client objects sounds really tough |
| 15:37 | <JakeA> | back later, going to try and get some of this talk done… |
| 15:42 | wanderview | is sad "Be my controlled document" won't fit on a candy heart. |
| 16:16 | <hswolff> | gsnedders i will treasure the time we had together |
| 17:24 | <hsivonen> | ISO-2022-JP, the Russian edition: https://bugzilla.mozilla.org/show_bug.cgi?id=1130533 (KOI8-R) |
| 17:24 | <hsivonen> | annevk: ^ |
| 17:25 | <gsnedders> | hsivonen: I presume the DECODER_INITIATED_* was the best you could do, and actually having what encoding a given page is would be too expensive and too much data? |
| 17:25 | <hsivonen> | I need to learn to WONTFIX stuff like that with less debate |
| 17:26 | <hsivonen> | gsnedders: I figured that counting pages is less interesting, because people might be loading the same thing over and over |
| 17:26 | <hsivonen> | gsnedders: if something isn't used in a session at all, it's a good indication that it doesn't matter |
| 17:26 | <hsivonen> | for that user |
| 17:27 | <hsivonen> | gsnedders: but when something is used, the number of times it is used doesn't really tell you much beyond needing to keep the functionality |
| 17:28 | <annevk> | hsivonen: so we removed it from the menu based on statistics right? |
| 17:28 | <hsivonen> | annevk: based on what the Thunderbird defaults were |
| 17:28 | <hsivonen> | annevk: i.e. no locale saw the need to default to KOI8-R for outgoing |
| 17:29 | <hsivonen> | annevk: and ru-RU even defaulted to UTF-8 |
| 17:29 | <annevk> | hsivonen: k, it doesn't seem as bad an encoding as iso-2022-jp, but yeah, dunno |
| 17:29 | <annevk> | hsivonen: wait, Firefox Nightly does still have this encoding as a preference |
| 17:29 | <hsivonen> | well, I'm not a SeaMonkey dev. they can do whatever they like as long as it doesn't affect the UI in mozilla-central |
| 17:30 | <hsivonen> | annevk: for the Web, yes |
| 17:30 | <hsivonen> | annevk: but there's no UI for choosing KOI8-R for the Web |
| 17:30 | <hsivonen> | as a default that is |
| 17:30 | <hsivonen> | annevk: sorry. let me try again |
| 17:31 | <hsivonen> | annevk: Firefox has this encoding in the menu. but not in the pref panel |
| 17:31 | <gsnedders> | hsivonen: ok, just been playing around with faster decoding, and would be interesting to know how many things are decoded with each, but not all too important |
| 17:31 | <hsivonen> | "Cyrillic" in the prefs means windows-1251 |
| 17:31 | <gsnedders> | hsivonen: just trying to use something as a somewhat arbitrary proxy :) |
| 17:33 | <hsivonen> | note to self: learn to be less easily trolled into using time to debate people who claim recipients can't deal with UTF-8 yet |
| 17:34 | <hsivonen> | btw, if one wants to combine the encoding topic and the EME topic (who doesn't?), just take a look at PlayReady PSSH boxes. |
| 17:35 | <hsivonen> | wasting bytes by making every second byte zero |
| 17:35 | <hsivonen> | because UTF-16 |
| 17:35 | <annevk> | heh |
| 17:35 | <annevk> | such great hobbies |
| 17:37 | <terinjokes> | annevk: i've been thinking on this vacation, wouldn't it be great if maybe, just sometimes, we had other hobbies? |
| 17:41 | <annevk> | terinjokes: I know one person that tried and didn't really succeed, although he did later quit his online persona |
| 17:43 | <terinjokes> | annevk: I'd argue I haven't succeeded on this vacation either. |
| 17:43 | <Ms2ger> | Why do you have an internet connection on vacation? |
| 17:44 | <jgraham> | Ooh, is this like a "why did the chicken cross the road" joke? |
| 17:44 | <jgraham> | "To get to the other side"? |
| 17:47 | <terinjokes> | Ms2ger: I have to book trains and hostels |
| 23:26 | <TylerH> | Hey TabAtkins, is this a good place to ask you about the status of ::before and ::after interactions with replaced elements? |
| 23:31 | <TylerH> | Specifically " Note. This specification does not fully define the interaction of :before and :after with replaced elements (such as IMG in HTML). This will be defined in more detail in a future specification. " from http://www.w3.org/TR/CSS21/generate.html#before-after-content (when will the specification define it in more detail?) |
| 23:34 | <TabAtkins> | TylerH: Either the Pseudo-Elements spec or the Content spec will define that. Hasn't been done yet. |
| 23:49 | <jgraham> | Hmm, I had to do search and replace on every third <td> element in a table, and I couldn't think of a cleverer way of doing it than n n <space>, and now I have We Will Rock You in my head |