| 00:04 | <jsbell> | MikeSmith: will do... |
| 00:05 | <jsbell> | MikeSmith: done |
| 00:05 | <jsbell> | Yeah, I think it predates some (all?) lint checks |
| 00:06 | <jsbell> | MikeSmith: dropping off now, so followups -> email/github. Thank you VERY much for your help! |
| 08:42 | <mkwst> | annevk: jochen__ just closed https://bugs.chromium.org/p/chromium/issues/detail?id=760096#c6 as WontFix, which reminded me how much I hate that `file:` URLs can have hostnames. |
| 08:42 | <mkwst> | Before I go through the trouble of adding metrics, would you fundamentally object to not allowing hostnames? :)( |
| 08:43 | <annevk> | mkwst: probably not, file URLs already have a lot of special cases in the parser |
| 08:43 | <annevk> | mkwst: it's probably worth raising an issue at the same time though since Node.js uses file URLs a fair bit too |
| 08:43 | <annevk> | mkwst: the other thing you could do of course is block them at the resolve layer |
| 08:43 | <mkwst> | I'd add metrics before raising an issue. No point in poking if there's no way to follow through. |
| 08:44 | <annevk> | mkwst: maybe that's cleaner |
| 08:44 | <mkwst> | Sure. Chrome could decide that it doesn't like the behavior. But I'd like other folks on board. |
| 08:44 | <mkwst> | Eh. I guess? I'm not sure what's simpler to implement, really, since I think we delegate to the OS for filesystem access. |
| 08:44 | <annevk> | We haven't really defined how file URLs resolve since it's platform dependent |
| 08:45 | <annevk> | You'd have to gate those calls somehow if you block at the resolve layer |
| 08:45 | <mkwst> | I haven't looked at any of the code. Maybe it's trivial. |
| 08:46 | <mkwst> | But I know it's trivial to remove the URL-parsing special case in Chrome's URL library, so. :) |
| 09:00 | <mkwst> | annevk: Hey, more file things! https://bugs.chromium.org/p/chromium/issues/detail?id=756416#c3 |
| 09:00 | <mkwst> | I'll file something against... HTML, I guess? |
| 09:01 | <mkwst> | Or maybe URL, which already hand-waves in the direction of opaqueness for `file:`? |
| 09:01 | <annevk> | mkwst: the main problem is getting user agents to agree |
| 09:01 | <annevk> | mkwst: is it consistently cross-origin in Chrome or can you still do XHR? |
| 09:01 | <mkwst> | Yeah. Which is why I'd file a bug for discussion. |
| 09:02 | <mkwst> | I'm just looking now, actually. I remember that we had some strange carveouts where we called the origin `file:` for all file URLs, but I don't recall the details. |
| 09:03 | <annevk> | mkwst: I guess it would be HTML, since URL gives an opaque origin for data URLs too, but that's not always what we do because of overrides |
| 09:03 | <mkwst> | Got it. |
| 09:03 | <annevk> | mkwst: Firefox has some kind of same-or-deeper directory thing going on |
| 09:04 | <mkwst> | Yeah. We considered that, but intentionally chose not to because of the downloads directory. |
| 09:04 | <annevk> | mkwst: it doesn't really seem worth it and will probably all go away the more we force HTTPS |
| 09:04 | <annevk> | mkwst: that's a compelling argument |
| 09:04 | <mkwst> | On the HTTPS note, I saw that you poked at dev-platform@ regarding pushing for secure contexts. |
| 09:05 | <mkwst> | Is there anything I can do there to help out? Other than poking at folks on Chrome's end in the same way? |
| 09:06 | <annevk> | mkwst: I need to talk to some more folks and at some point I mean to investigate what Chrome has disabled and Firefox has not |
| 09:06 | <annevk> | mkwst: if the latter is available somewhere that'd be swell, but I don't see anything else right now (other than pushing the worklets folks up the hill and getting a story for CSS and such) |
| 09:07 | <annevk> | mkwst: agreed with your review on the TAG PR too, FWIW |
| 09:07 | <mkwst> | There's an internal thread among API owners that wasn't actually meant to be internal. Will try to externalize that when folks wake up. |
| 09:08 | <annevk> | I saw the public thread, but there weren't many convincing arguments there |
| 09:08 | <mkwst> | But it's more or less the same story. slightlyoff, jochen__, and I are the bad cops. |
| 09:09 | <annevk> | The resistance mostly seems to be that transition is hard |
| 09:10 | <annevk> | But the argument also changes, since first the resistance was that it would be too expansive or too slow |
| 09:23 | <nox> | annevk: I need a poster image for a <video> in wpt, |
| 09:23 | <nox> | annevk: what image should I use? |
| 09:23 | <nox> | Oh, media/poster.png |
| 09:25 | <annevk> | Glad you found something 😊 |
| 09:27 | <nox> | Hah. :) |
| 09:27 | <nox> | annevk: Almost done with them tests, |
| 09:28 | <nox> | annevk: and I have a question: there is nothing that lets me know whether a poster frame loaded, apart from making sure the poster frame starts loading before the document's load event, so that I can do stuff in the onload handler? |
| 09:30 | <annevk> | nox: I don't know about that either |
| 09:30 | <annevk> | nox: I was really only closely involved with <video> before it became all complicated |
| 09:32 | <nox> | annevk: Hah! |
| 09:33 | <nox> | annevk: tfw local clone is thousands of commits in the past and you need to push all of them to make a PR with a single test |
| 13:09 | <annevk> | And as we get closer to requiring UTF-8 all over, XMLHttpRequest and Firefox have to regress on that point: https://github.com/whatwg/xhr/issues/159 |
| 13:09 | <annevk> | It even had a test, but I suspect no bugs were filed back then |
| 13:10 | <annevk> | Makes me wonder whether we test fetch() for this |
| 15:30 | <wanderview> | JakeA: do you know who knows about chrome performance timeline stuff with service workers involved? |
| 15:35 | <wanderview> | just trying to figure out: https://github.com/w3c/resource-timing/issues/119 |
| 15:39 | <JakeA> | wanderview: falken maybe? |
| 15:40 | <wanderview> | JakeA: ok... I pinged him in the github issue... thanks |
| 15:40 | <wanderview> | these values are pretty confusing right now |
| 17:33 | <ondras> | damn, apparently font-size:calc(1vw*1vh) is not possible :/ |
| 17:33 | <ondras> | why not? sounds like a useful idea. |
| 17:38 | <Domenic> | annevk: mkwst: according to https://quuz.org/url/liveview.html#file://x.jd.com/mkt/pcwap?&callback=dsp_1504020242543&r=1504020242544 in Firefox there is no hostname there, at least. So that's a point in its favor. |
| 18:00 | <mkwst> | Domenic: Great! Go file a bug against every other browser to align with Firefox! |
| 18:27 | <Krinkle> | JakeA: I'm curious about your thoughts on Wikimedia's approach to the client-side caching of javascript/css module bundles. As you might know, we currently do it as follows (in a nut shell): JS has a module manifest (dependency tree and version hashes), and an array of modules names to load on this page. For each module+version key it checks localStorage, and if present, evals it. Any remaining modules are fetched from the server in 1 batch |
| 18:27 | <Krinkle> | request. On response, after normal execution, we also stash each module's response closure from the batch request into localStorage. |
| 18:27 | <Krinkle> | I've considered using ServiceWorkers and/or its Cache API in various ways over the past 2 years but always came back to the current solution. |
| 18:29 | <TabAtkins> | ondras: Because it's multiplying a length by a length, so the unit ends up being length^2. (V&U 4 will allow unit algebra, so you can divide that expression by 1px and get back to a plain length, and that's already specified in the TypedOM spec.) |
| 18:29 | <ondras> | @TabAtkins: yeah, I would happily divide that by Npx to get to a reasonable unit |
| 18:30 | <ondras> | TabAtkins: ^ (sorry for bad highlight) |
| 18:30 | <Krinkle> | The main reason I want to get out of localStorage is because it's synchronous and because it's limited and is sometimes breaking user features when its full (e.g. 99% full with js/css, no space for "normal" usage like small key/value pairs for things like hiding notices or keeping track of collapsed/expanded state of something). |
| 18:30 | <ondras> | ideally, I would like to take a square root tho |
| 18:32 | <Mek> | replacing localstorage usage with cache API usage or something definitely sounds like a sensible thing to do |
| 18:38 | <Krinkle> | At first I tried the "obvious" way with proper ServiceWorker intercepting network requests, and disabling the main thread logic of using localStorage. |
| 18:40 | <Krinkle> | That means the SW thread needs to unpack the request url to find the raw list of module names again, then it needs access to the module manifest (postMessage, or separate request), and then for each moduleName/moduleVersion, construct a non-batch fake url and do cache lookups, then the logic is essentially the same as before: Make a batch request for the cache misses, and then mimick the server-side's logic of concatenating the hits from Cache |
| 18:40 | <Krinkle> | and cache-miss-batch responses. |
| 18:40 | <Krinkle> | The downside is that now the whole thing is a lot slower. we used to eval modules right away from those that are in the cache. I don't wanna block those on 1 cache miss. |
| 18:40 | <Krinkle> | And JS responses don't stream execution. |
| 18:42 | <Krinkle> | So it seems more natural to ditch the SW part of it, and do the cache lookups in the main thread instead, but that means resorting to eval again, which is fine I suppose, (as long as V8's parse cache still works, which seems to be fine for us at the moment). |
| 18:44 | <wanderview> | Krinkle: what do you mean by "And JS responses don't stream execution." |
| 19:00 | <Krinkle> | wanderview: Given 10 keys, where 8 are going to hit cache. We currently read from localStorage, eval, and then request 2 from network. At this point, the first 8 modules are not waiting or blocked, they're executed and are done. |
| 19:01 | <Krinkle> | If I'd do the same in SW, I'd have to wait for the batch request for the remaining 2 modules in order to concat the response and send it back to the client. |
| 19:01 | <Krinkle> | E.g. given the client making a request for 10, SW.js unpacking it and composing it of 8 cache entries and the real request for 2 more. |
| 19:01 | <wanderview> | Krinkle: even with ReadableStream in the service worker script? |
| 19:01 | <Krinkle> | wanderview: I can stream alright, but JS doesn't execute in a streaming way. |
| 19:02 | <Krinkle> | Even if Chrome/V8 does streamed parsing (does it?), it certainly won't execute any JS code until the last byte arrives afaik. |
| 19:02 | <wanderview> | Krinkle: ah, ok |
| 19:03 | <gsnedders> | well you can't given JS semantics |
| 19:03 | <gsnedders> | oh wait that was literally your previous line |
| 19:04 | <Krinkle> | Yeah, I get it. I'm not blaming the browser here. Just looking for a suitable way to get this stash out of localStorage without making things worse :) |
| 19:05 | <wanderview> | Krinkle: I wonder if streaming html with <script> tags would let them evaluate incrementally |
| 19:06 | <gsnedders> | wanderview: yes |
| 19:06 | <Krinkle> | wanderview: Yeah, I suppose it would. but is there a way to stream HTML into an existing browsing context? Maybe with an iframe, that then accesses the parent. |
| 19:06 | <Krinkle> | but I don't expect code to then work as-is. |
| 19:06 | <Krinkle> | Any use of 'window' or 'document' would be broken. |
| 19:07 | <Krinkle> | For a single script that would work, but not with e.g. existing code base or something like jquery.js or any standard lib. |
| 19:07 | <Krinkle> | dependency injection is nice, but use of browser APIs directly is quite common, DI in JS hasn't gotten much traction yet. |
| 19:16 | <Krinkle> | gsnedders: wanderview: JakeA: Thanks for your input :-) I summarised it again at https://github.com/w3c/ServiceWorker/issues/1203 |