| 00:56 | <Domenic> | annevk: workers currently use "same-origin"? So they don't work cross origin at all?? |
| 00:57 | <Domenic> | I think I'll just loosen that... |
| 01:11 | <Domenic> | this turns out to be something web developers are doing massive hacks to get around |
| 01:11 | <Domenic> | hosting .html files on a domain that postmessage back and forth |
| 01:11 | <Domenic> | i am happy with my decision to loosen this |
| 01:16 | <zcorpan> | Domenic: i would think this is something that has been discussed before. i don't recall off the top of my head but i think this is something that we'd allow at some point but there are some security things to consider, maybe for shared workers in particular |
| 01:16 | <Domenic> | yeah maybe i am getting overzealous here... |
| 01:16 | <Domenic> | i can probably manage not to for now |
| 03:48 | <MikeSmith> | beverloo: https://tools.ietf.org/id/draft-thomson-webpush-vapid-02.html doesn't define any requirements for UAs? |
| 03:51 | <MikeSmith> | beverloo: the interaction is strictly between a conforming Application Server being required to send a JWT to make use of the feature, and a conforming Push Service being required to act on that as specified? |
| 05:00 | <tripu> | mkwst, yt? |
| 06:50 | <annevk> | I think CORS workers might be fine, as long as they execute with the correct origin |
| 09:34 | <annevk> | So I'm guessing I need to update all the build script things to continue doing things? |
| 09:34 | <annevk> | Domenic: thank you for the review on cross-origin objects, much appreciated |
| 09:51 | <MikeSmith> | annevk: yeah, please start by pulling from the watssi repo and rebuilding it |
| 09:51 | <MikeSmith> | then the html-build repo |
| 09:54 | <MikeSmith> | though there's still a lot that needs to be done yet to eliminate the need to rebuild the cldr and entity stuff every single time |
| 09:55 | <MikeSmith> | But the state of master in both places is progress |
| 10:05 | <beverloo> | MikeSmith, there are two concepts in that draft |
| 10:05 | <beverloo> | (1) server authentication, which is between the application server and the push service |
| 10:06 | <beverloo> | and (2) subscription restriction (ne� subscription association), which uses the public key of said authentication to link a subscription to a certain application server |
| 10:06 | <annevk> | MikeSmith: what did you think of my suggestions in that thread? |
| 10:06 | <beverloo> | the UA implication of creating a subscription restriction is documented in 5.1, with the Crypto-Key header |
| 10:06 | <beverloo> | W3C PR is here: https://github.com/w3c/push-api/pull/182 |
| 10:15 | <annevk> | Documented merge policy for Notifications API |
| 10:16 | <annevk> | Will slowly copy-and-paste that throughout repositories, it basically defers to whatwg/html TEAM |
| 10:21 | <JakeA> | Is it fair to say that the way <link rel="stylesheet"> blocks rendering until the sheet loads is totally undefined? |
| 10:23 | <beverloo> | annevk, thanks :) much more discoverable! |
| 10:28 | <annevk> | JakeA: rendering is mostly undefined |
| 10:28 | <annevk> | JakeA: we sorta defined when it can happen |
| 10:28 | <JakeA> | annevk: right, but I don't see anything that skips rendering if there's a pending stylesheet |
| 10:29 | <annevk> | Yeah I don't think that exists, stylesheet loading is also somewhat tricky due to media queries |
| 10:29 | <annevk> | We do define that <script>s are blocked based on stylesheets that need to load I think |
| 10:30 | <annevk> | Although you could implement that by halting script execution the moment script asks for something layouty, like getComputedStyle() |
| 10:30 | <annevk> | Script asking for something layouty is also not defined |
| 10:30 | <annevk> | I keep hoping zcorpan will get to that one day |
| 10:33 | <Ms2ger> | annevk, spec does say "feel free to stop blocking scripts at any time", though |
| 10:34 | <annevk> | That is not a literal quote it seems |
| 10:34 | <Ms2ger> | It is not :) |
| 10:34 | <Ms2ger> | Look for pending script-blocking stylesheet or something along those lines |
| 11:17 | <mounir> | heycam|away: ping |
| 12:20 | <annevk> | So now you can no longer annotate PDFs with signatures in Acrobat Reader unless you buy some pro option, what's a good alternative? |
| 12:28 | <annevk> | It seems I'm dumb and Preview can handle that perfectly fine still |
| 12:28 | <annevk> | So maybe I should just review Adobe software |
| 12:28 | <annevk> | s/review/remove/ |
| 12:29 | <MikeSmith> | beverloo: thanksーit's interesting to finally see all the Push stuff becoming real |
| 13:14 | <MikeSmith> | annevk: which thread? > what did you think of my suggestions in that thread? |
| 13:15 | <annevk> | MikeSmith: https://github.com/whatwg/html-build/issues/62#issuecomment-177497253 |
| 13:17 | <MikeSmith> | ah that yeah |
| 13:18 | <MikeSmith> | annevk: yeah I pretty much agree. It seems like we're really over-automating it all |
| 13:20 | <MikeSmith> | I think it makes sense to keep the existing build tooling that we have for generating the end results, but we can just periodically run it manually to see if anything's actually changed would cause a diff in the spec |
| 13:21 | <MikeSmith> | just eyeball it, and if we find that anything's changed, then as you said, somebody just opens a PR and somebody else reviews it, etc. |
| 13:22 | <annevk> | I'll see if I can make a suitable PR for the entity stuff |
| 13:22 | <MikeSmith> | OK |
| 13:22 | <annevk> | A proper fix for the CLDR stuff would involve new specification text I think |
| 13:22 | <MikeSmith> | yeah I guess so |
| 13:23 | <MikeSmith> | it's sort of moot since maybe nobody actually is even attempting to follow the spec on that |
| 13:23 | <MikeSmith> | but instead using whatever result they get from their own ICU integration |
| 13:23 | <MikeSmith> | and maybe not even that |
| 13:23 | <MikeSmith> | but the entities stuff is different, as you pointed out |
| 13:24 | <annevk> | that would be more or less what we require though |
| 13:24 | <MikeSmith> | so yeah I think re-wording the requirements along those lines would be an improvement |
| 13:24 | <MikeSmith> | and would address the "moving target" problem that philipj pointed out |
| 13:26 | <MikeSmith> | anyway the entities stuff more clearly has actual impact and I agree that we should not just be silently introducing changes to the spec from the build without noticing it |
| 13:26 | <MikeSmith> | or rather more like we should only be intentionally changing those requirements and never unintentionally |
| 13:27 | <MikeSmith> | well stated like that, it's true of anything in the spec of course |
| 13:27 | <MikeSmith> | but you know what I mean |
| 13:27 | <Ms2ger> | Are there other parts of the spec that change silently? |
| 13:28 | <MikeSmith> | good point |
| 13:28 | <MikeSmith> | yeah it doesn't actually happen |
| 13:29 | <MikeSmith> | in practice when we ran the entities build stuff and it actually resulted in a difference, we would notice |
| 13:30 | <MikeSmith> | and then we would decide whether to actually commit the resulting change or not |
| 13:42 | <beverloo> | MikeSmith, yes :) we're implementing it in both gcm and chrome |
| 13:42 | <beverloo> | Mozilla will adopt as well, which will bring our implementations completely in line |
| 13:43 | <MikeSmith> | super |
| 13:43 | <Ms2ger> | gcm? |
| 13:45 | <beverloo> | Google Cloud Messaging, our backend for the Push API |
| 13:54 | <annevk> | Oh my, trying to extract the entity stuff is harder than I thought |
| 13:54 | <annevk> | bash is not for me I think |
| 13:55 | <Ms2ger> | I don't think bash is for anyone |
| 14:00 | <MikeSmith> | sure it is |
| 14:00 | <MikeSmith> | that's what TimBl said at the Olympics |
| 14:00 | <annevk> | So it's not even clear to me what we want to do here |
| 14:00 | <MikeSmith> | "Bash is for everyone" |
| 14:00 | <annevk> | We could store unicode.xml, we could just store the output of that |
| 14:01 | <MikeSmith> | we just need the output of it |
| 14:01 | <MikeSmith> | we don't need to store unicode.xml |
| 14:01 | <annevk> | Yeah, I think we want some kind of build-entities.sh script |
| 14:01 | <annevk> | And put that in whatwg/html |
| 14:01 | <annevk> | And store the final entity files in whatwg/html too |
| 14:02 | <annevk> | And remove everything from html-build except for merging those entity files into the final output |
| 14:03 | <annevk> | Does that make sense? That way entities and any changes to them become version controlled and whenever someone wants to change them you just run the build-entities.inc script and create a PR for that |
| 14:05 | <Ms2ger> | That sounds reasonable |
| 14:05 | <MikeSmith> | I agree we whould put the output in whatwg/html under version control |
| 14:05 | <MikeSmith> | but I suspect that Domenic would say that we don't want build scripts in the html repo |
| 14:06 | <MikeSmith> | and I pretty much agree with that |
| 14:06 | <nox> | Ms2ger: Like JS? :3 |
| 14:06 | <nox> | (That bash isn't for anyone.) |
| 14:07 | <Ms2ger> | No comment |
| 14:07 | <annevk> | MikeSmith: I guess we can put the actual script in html-build |
| 14:07 | <MikeSmith> | annevk: yeah, and it can write the output back to the html repo |
| 14:08 | <MikeSmith> | if we want to do it that way |
| 14:08 | <annevk> | MikeSmith: yeah |
| 14:10 | <annevk> | MikeSmith: you know, I'll give it a go and I'll keep asking questions here |
| 14:11 | <MikeSmith> | good plan |
| 14:13 | <nox> | Ms2ger: Hah. |
| 14:33 | <annevk> | MikeSmith: how does entities-dtd.url end up in the HTML standard? |
| 14:33 | <annevk> | MikeSmith: I have a somewhat standalone bash script now that generates all these files (though not super clean yet), but I'm not sure how to hook up the pieces |
| 14:40 | <annevk> | I think I found it, pre-process-main.pl does some magic |
| 14:40 | <annevk> | Pfff |
| 14:41 | <MikeSmith> | yeah that |
| 14:46 | <Domenic> | JakeA: what is a URI? :( :( :( |
| 14:46 | <nox> | Domenic: An amputated URL. |
| 14:46 | <JakeA> | Domenic: I went with the wording in document.baseURI |
| 14:47 | <jgraham> | It's a URL that says "I hang out with Roy" |
| 14:47 | <Domenic> | JakeA: legacy API boo |
| 14:48 | <annevk> | Ah, I need to consistently annotate those with [sic] just like we do with Referer |
| 14:48 | <annevk> | Folks keep copying from that pattern rather than something like new URL() |
| 14:49 | <JakeA> | Domenic: ah, had no idea it was legacy. What's the non-legacy version? |
| 14:50 | <Domenic> | JakeA: oh there's no replacement. Just it is a legacy name. |
| 15:02 | <annevk> | But yeah, the HTML standard calls this the "base URL" |
| 15:03 | <annevk> | I still think it would be super weird if service workers ended up with a different answer there from the rest of the platform, although that redirect case you pointed out is interesting (and probably a security bug) |
| 15:03 | <ondras> | hmm, is it possible to extend an ES6 class using ES5 syntax, i.e. class Parent {}; var Child = function() { Parent.call(this, throws); } ? |
| 15:05 | <Domenic> | ondras: no |
| 15:06 | <ondras> | Domenic: okay, and via Reflect.construct ? |
| 15:06 | <Domenic> | ondras: pretty sure still no, but maybe there is a clever hack |
| 15:07 | <ondras> | Domenic: okay, thanks |
| 15:10 | <Domenic> | annevk: @fetchstandard should retweet https://twitter.com/webkit/status/694536332941627393 |
| 15:10 | <Domenic> | Also http://trac.webkit.org/changeset/195954 "reviewed by Darin Adler" |
| 15:15 | <JakeA> | annevk: I don't think it's as simple as that. Firefox may use response.url as the base for pages, but that's not in the spec, and SW is the first time it matters vs request.url |
| 15:16 | <JakeA> | annevk: fwiw, developers seem to be thinking of the SW as a server, so they're happy for even CSS to get the base of the request url in SW responses :/ |
| 15:16 | <annevk> | JakeA: I suspect Firefox doesn't actually do that, I'm just saying that you can explain the entire platform today through that behavior |
| 15:16 | <annevk> | JakeA: that was the original argument, but we wanted fetch() to be a no-op |
| 15:17 | <JakeA> | annevk: yeah, surprised that devs don't seem to want that. Going to make sure those that run large SW projects chime in (eg Guardian, who rely on pass-through fetch) |
| 15:21 | <annevk> | I'm somewhat uncomfortable by the way we seem to go about deciding this |
| 15:22 | <annevk> | E.g., a proxy server cannot trigger dialogs either, should we remove the window feature? |
| 15:22 | <annevk> | What about mixed content? |
| 15:22 | <annevk> | I really wish it was a bit more principled rather than ad-hoc |
| 15:47 | <annevk> | MikeSmith: supplied PRs |
| 15:48 | <annevk> | MikeSmith: Domenic: I tested it locally and it seems to work fine |
| 17:34 | <annevk> | philipj: Domenic: downloading here is nearly instant... generating is what you call slooow |
| 17:34 | <annevk> | philipj: Domenic: maybe because of my 2012 MacBook Air, I guess you both might have a Pro? |
| 17:35 | <Domenic> | annevk: there are two kinds of generating... the initial "building the database" from unicode.xml, and the creation of the .inc and .xml files |
| 17:35 | <Domenic> | I think currently it does unicode.xml -> database -> { .inc, .json, .url }, with the first arrow being slow |
| 17:36 | <Domenic> | If we turned it into .json -> { .inc, url } that should be fast |
| 17:36 | <Domenic> | (with a precomutation of unicode.xml -> database -> .json) |
| 17:37 | <annevk> | Hmm, I'm not super happy on spending much more time on this, but if you both are... |
| 17:39 | <annevk> | I see your point of view about source of truth though, but that would mean we should check in unicode.xml rather than the output of our scripts |
| 17:40 | <annevk> | Otherwise you're always somewhere in the middle |
| 17:42 | <Domenic> | it depends... I think it would be OK to check in entities.json and then have a update-entities-json that pulls in unicode.xml. That will generate readable entities.json diffs |
| 18:03 | <Domenic> | All right, you guys didn't exactly thrill me with your brainstorming last time, but what's a good example of a module worker. Basically, what's a good example of a small worker that might need to call out to a library. |
| 18:04 | <annevk> | Domenic: some networking worker that imports a library from a service? |
| 18:06 | <annevk> | import starwars; starwars.findAll("rey").then(...) |
| 18:07 | <Domenic> | seems reasonable, i can work with that |
| 18:08 | <igrigorik> | annevk: would love to hear your thoughts on https://github.com/w3c/preload/issues/55 < getting lots of inbound pings from developers asking for this. |
| 18:09 | <annevk> | igrigorik: expose more Fetch parameters? |
| 18:10 | <annevk> | igrigorik: the alternative would be that "as" doesn't map to "type", but that it maps to "initiator" and we just add a bunch of stuff there |
| 18:10 | <annevk> | igrigorik: worker/sharedworker should be "script" though I think |
| 18:12 | <igrigorik> | re-reading through the spec.. I guess extending initiator would do the trick. although I'm not entirely clear on difference between initiator and type? |
| 18:21 | <annevk> | igrigorik: type is a category |
| 18:21 | <annevk> | igrigorik: initiator is ideally a single thing |
| 18:21 | <annevk> | igrigorik: though it's also a bit of a hack, see https://github.com/whatwg/fetch/issues/93 |
| 18:29 | <smaug____> | Any googlers with good contacts to AdSense team? |
| 18:34 | <igrigorik> | annevk: ah, right.. trying to page that discussion back into my head. |
| 18:34 | <igrigorik> | annevk: http://output.jsbin.com/teyede < wdyt? |
| 18:35 | <annevk> | I think we should only have initiator |
| 18:36 | <annevk> | But for <object> that becomes a little weird |
| 18:36 | <annevk> | Is the <a> that targets it the initiator? |
| 18:36 | <igrigorik> | agreed, I just added new column so we can compare, we definitely don't need both |
| 18:37 | <annevk> | Same for <iframe> and such |
| 18:37 | <annevk> | That's why we added the destination column |
| 18:42 | <igrigorik> | yeah, except destination doesn't help the preload use case.. I'm thinking we can just split the initiator further -- e.g. break object/embed apart, and give iframe/frame their own? |
| 18:51 | <igrigorik> | annevk: another attempt @ https://docs.google.com/spreadsheets/d/1YXoso_Vm0tCuGjFxNmD70UlQd87PKIgGBM97DG9E2L0/edit#gid=0 (easier to iterate on it in a spreadsheet :)) |
| 18:59 | <igrigorik> | annevk: if that looks ~reasonable, I can PR it. |
| 19:00 | <wanderview> | jsbell: I think I reviewed something in critic... |
| 19:01 | <jsbell> | That's how much confidence I have in my use of critic too |
| 19:07 | <wanderview> | jsbell: any thoughts on when the .add() and .addAll() changes might happen in blink? |
| 19:09 | <jsbell> | wanderview: which specifically? (sorry, I haven't been thinking about SW/Cache at all lately) |
| 19:09 | <wanderview> | jsbell: making them reject if any response.ok() returns false |
| 19:09 | <wanderview> | to prevent 40x and 50x responses getting cached |
| 19:09 | <jsbell> | ah, right. checking... |
| 19:17 | <jsbell> | wanderview: not even finding a tracking bug on that. :P Seems easy though. (aside; need to ensure the JakeA -> crbug pipeline is unclogged) |
| 19:19 | <jsbell> | wanderview: crbug.com/583407 I'll try and bash that out |
| 19:36 | <annevk> | igrigorik: I guess the problem is that those are not the actual initiators |
| 19:36 | <annevk> | igrigorik: e.g., often it would be <a> or <form> |
| 19:38 | <wanderview> | jsbell: I'm going to try to get it in FF45 which releases mid-March... want to minimize chance people start using opaque responses a lot in their caches |
| 19:45 | <igrigorik> | annevk: current definition doesn't seem to address that either though, right? |
| 19:45 | <smaug____> | anyone seen rniwa? |
| 19:46 | <igrigorik> | annevk: or, I guess <a> would fall under "HTML's navigate algorithm" row? |
| 19:49 | <annevk> | igrigorik: <a> and <form> are navigate |
| 19:49 | <annevk> | igrigorik: as is <iframe src> |
| 19:49 | <annevk> | igrigorik: <object src> is ambiguous |
| 19:50 | <annevk> | <a> targeted at <object> is ambiguous (may or may not work, depending on what mode <object> is in) |
| 19:53 | <igrigorik> | right, ok. so, perhaps "initiator" is not the right tool for the job here then? |
| 19:54 | <annevk> | yeah, several axes might be the way to go after all |
| 19:55 | <annevk> | axis? |
| 19:58 | <igrigorik> | hmm, what if we "refined" destination? https://docs.google.com/spreadsheets/d/1YXoso_Vm0tCuGjFxNmD70UlQd87PKIgGBM97DG9E2L0/edit#gid=0 (reload) |
| 20:01 | <annevk> | that seems more reasonable, basically splitting subresource |
| 20:01 | <annevk> | well, and unknown |
| 20:05 | <igrigorik> | yep. should I take a run at a PR? |
| 20:08 | <annevk> | igrigorik: I think it would be good to start with an issue to get feedback from the people that helped design type/destination |
| 20:08 | <annevk> | igrigorik: I'd like to hear what ehsan and sicking think |
| 20:08 | <annevk> | igrigorik: issue + PR is fine too though |
| 20:08 | <igrigorik> | sgtm, on it. |
| 20:09 | <jsbell> | wanderview: merged! |
| 20:09 | <wanderview> | thanks! |
| 20:09 | <jsbell> | now AFK |
| 20:09 | <wanderview> | jgraham_: can you let me know when we next merge wpt to gecko? |
| 20:10 | <jsbell> | (the indexeddb test fixes should be much simpler) |
| 20:21 | <annevk> | igrigorik: quite a neat solution I think |
| 20:21 | <annevk> | igrigorik: hopefully that feeling remains 😃 |
| 20:35 | <jgraham_> | wanderview: Is that a request? I can kick it off now if you like |
| 20:45 | <wanderview> | jgraham_: if its not too inconvenient... I have a bug I want to implement soon, but I'd like to base it on top of jsbell's test changes |
| 20:45 | <wanderview> | tomorrow is fine too |
| 20:48 | <Domenic> | worker modules \o/ |
| 20:52 | <jsbell> | wanderview; will you fail everything in an addAll batch if any response is !ok? |
| 20:52 | <wanderview> | jsbell: I thought that was the intention |
| 20:52 | <jsbell> | wanderview: I'm still parsing the discussion |
| 20:52 | <wanderview> | jsbell: I guess we could clarify with JakeA (but I hear he is at the pub) |
| 20:54 | <jsbell> | wanderview: implication, then, is that everything is delayed until we have headers back on all of them, which is a bit of a bummer, but I suppose you can just add() in a loop instead if you want speed. |
| 20:55 | <wanderview> | jsbell: we already need that in order to do the "reject if an entry matches an earlier entry in the same addAll()" because matching requires vary header stuff |
| 20:58 | <jsbell> | wanderview: ... right. Okay, and we already do wait in our code. So ignore me, carry on. :) |
| 20:59 | <wanderview> | jsbell: while you are looking at it... do you guys do the "incumbent record" stuff that lets .match() read a response whose body is till being written to disk? |
| 20:59 | <wanderview> | my impression is no one implements that yet |
| 21:04 | <jsbell> | wanderview: so far as I can tell, no - we wait for the content to be fully streamed into the cache before we execute the next cache operation (e.g. match) |
| 21:04 | <wanderview> | ok, thanks |
| 21:05 | <jsbell> | its a maze of twisty callbacks all alike, so I may have missed something |
| 21:05 | <wanderview> | we allow matches to continue, but don't commit the .put() or .add() until the body is completely there |
| 21:05 | <wanderview> | jsbell: JakeA has a cache transaction proposal to fix compat on that issue |
| 21:05 | <jsbell> | our cache doesn't have fancy transaction semantics |
| 21:06 | <wanderview> | we don't have fancy transactions either... but we store the body in flat files, so we don't touch the underlying DB until its fully on disk |
| 21:42 | <jsbell> | wanderview: FYI, add/addAll !ok test changes: https://codereview.chromium.org/1664473002/diff/1/third_party/WebKit/LayoutTests/http/tests/cachestorage/script-tests/cache-add.js?context=10&column_width=80&tab_spaces=8 |
| 21:43 | <wanderview> | thanks |
| 21:50 | <heycam> | mounir: pong |
| 21:55 | <jgraham_> | wanderview: It can take a while for upgrades to get the minimum of two required try runs, so if I start now it may or may not be done by tomorrow |
| 21:56 | <wanderview> | jgraham_: that would be fine... whatever is convenient for you... if it waits another day its not a crisis |
| 21:59 | <wanderview> | jsbell: what are you rejecting addAll() with for !ok()? |
| 22:50 | <jsbell> | wanderview: TypeError |
| 23:11 | <MikeSmith> | annevk: looking at build PRs now |