| 05:59 | <MikeSmith> | heycam: If you're around, I have what I hope is a related to WebIDL use in the HTML spec that should be quick to answer |
| 05:59 | <heycam> | MikeSmith, hi! sure. |
| 05:59 | <MikeSmith> | heycam: ok, in https://html.spec.whatwg.org/multipage/infrastructure.html#safe-passing-of-structured-data |
| 05:59 | <MikeSmith> | or more specifically in https://html.spec.whatwg.org/multipage/infrastructure.html#internal-structured-cloning-algorithm |
| 06:00 | <MikeSmith> | the If input is an Object object |
| 06:00 | <MikeSmith> | the "If input is an Object object" case |
| 06:00 | <MikeSmith> | that should in fact be uppercase "Object", right? |
| 06:00 | <MikeSmith> | I mean it's right as-is |
| 06:01 | <MikeSmith> | it should not be lowercase "object" |
| 06:01 | <heycam> | MikeSmith, yes, I think it's right to be Object |
| 06:01 | <heycam> | since below that it says that those names are used to check against [[Class]] |
| 06:01 | <MikeSmith> | ok |
| 06:01 | <heycam> | mind you, [[Class]] doesn't exist any more in ES6 |
| 06:02 | <MikeSmith> | lemme check I think there is once more instance I wanted to conform |
| 06:02 | <MikeSmith> | oh |
| 06:02 | <MikeSmith> | will we have to update the HTML spec then? |
| 06:02 | <MikeSmith> | with regard to that |
| 06:03 | <heycam> | yeah, it should. |
| 06:03 | heycam | wonders what to |
| 06:03 | <heycam> | I have loose language in the IDL spec like "if V is a Dat object, ..." |
| 06:03 | <heycam> | *Date |
| 06:03 | <heycam> | but I need to make that more precise |
| 06:03 | <MikeSmith> | hmm yah |
| 06:04 | <heycam> | http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.prototype.tostring does checking for particular internal slots, to determine what to return from Object.prototype.toString |
| 06:04 | MikeSmith | looks |
| 06:05 | <heycam> | so to the extent that we need to do type checking of JS objects, maybe we should have some common definition that does the same checks |
| 06:05 | <MikeSmith> | yeah that would seem to make sense |
| 06:06 | <heycam> | another point is that newer objects like Map and Set get their appropriate Object.prototype.toString value from their @@toStringTag property |
| 06:07 | <MikeSmith> | so? |
| 06:07 | <heycam> | so specific checks like for [[MapData]] might be warranted there |
| 06:07 | <annevk> | zcorpan: do you not have Wattsi setup? |
| 06:08 | <MikeSmith> | heycam: ah ok |
| 06:08 | <MikeSmith> | wait wat is a "exotic String object" |
| 06:08 | <heycam> | then for all of the IDL-interface-typedef things, like ImageData, it's sufficient just to say "if input is an ImageData object" |
| 06:08 | <heycam> | as the IDL spec assumes that we can tell that an object is a platform object implementing a particular IDL interface |
| 06:08 | <MikeSmith> | ah yeah I see, that would be preferable |
| 06:08 | <MikeSmith> | yeah |
| 06:09 | <heycam> | but yeah a single algorithm "if an X is a Y object" that does all that would be helpful |
| 06:09 | <annevk> | MikeSmith: so I think we want to move structured cloning into IDL... |
| 06:09 | <MikeSmith> | I support any plan that pushes all the hard work to the WebIDL spec |
| 06:09 | <annevk> | MikeSmith: since it's an ECMAScript extension in part it doesn't really fit well in HTML |
| 06:10 | <MikeSmith> | annevk: yeah I think there is a note about that somewhere |
| 06:10 | <MikeSmith> | yup |
| 06:10 | <heycam> | probably makes sense yeah |
| 06:11 | <MikeSmith> | annevk: in the mean time it would be nice to clear away as many of the XXX comments in the source as we can. It's a minor thing but to me at least it's not very helpful to have the build just spit that list out at end every single time |
| 06:11 | <MikeSmith> | because in practice we then just ignore that list |
| 06:11 | <annevk> | MikeSmith: I would accept a PR that changes them to "TODO" |
| 06:12 | <MikeSmith> | OK well then the disappear completely and we never get back to fixing them |
| 06:12 | <annevk> | MikeSmith: my understanding is that XXX can be used while making edits, it should not be used for things that end up in a commit |
| 06:12 | <MikeSmith> | ah ok |
| 06:12 | <annevk> | MikeSmith: we should probably track TODO separately somehow, or file issues on them |
| 06:13 | <MikeSmith> | OK well then I would like to fix/remove the existing XXX ones that we can fix/remove, then after that, change the remaining ones to TODOs |
| 06:14 | <MikeSmith> | I can make a PR for that |
| 06:16 | <MikeSmith> | annevk: and maybe I can for that PR just make an xxx-removal branch, and then everybody reviews the existing XXX things and we all just push changes to the branch for any we have information for that we can resolve |
| 06:16 | <MikeSmith> | all work off the same branch |
| 06:17 | <MikeSmith> | OK> |
| 06:17 | <MikeSmith> | OK? |
| 06:18 | <annevk> | MikeSmith: sure |
| 06:19 | <annevk> | MikeSmith: got distracted, but that seems totally fine |
| 06:19 | <zcorpan> | annevk: no, haven't attempted yet |
| 06:20 | <annevk> | zcorpan: that might be a good idea, especially when supplying patches that are more than a typo fix |
| 06:21 | <zcorpan> | annevk: yes :-) |
| 07:08 | <MikeSmith> | zcorpan: several of those existing XXX comments seem to be in the source of the image section |
| 07:18 | <zcorpan> | MikeSmith: yeah |
| 07:39 | <annevk> | MikeSmith: so yeah, I looked at that Object thing and fixing it is kind of a rabbit hole |
| 07:39 | <annevk> | MikeSmith: I would be okay with just removing the XXX thing though and filing an issue on structured cloning |
| 07:45 | <MikeSmith> | aok |
| 07:45 | <annevk> | MikeSmith: btw, if I want to update Wattsi, what do I do? Just run build.sh and hope for the best? |
| 07:46 | <annevk> | MikeSmith: is DEFINES="-dUSEROPES -dLINES -dPARSEERROR -Px86_64" still needed with your fix? |
| 07:48 | <MikeSmith> | annevk: yeah it should just (re)compile. If it doesn't then that's a bug on whoever made the change that broke its build |
| 07:48 | <MikeSmith> | you can drop -Px86_64 now |
| 07:49 | <annevk> | MikeSmith: so one thing that would be great for you to host would be the email archives... |
| 07:49 | <annevk> | MikeSmith: that would substantially improve the status quo, though might be tricky |
| 07:50 | <MikeSmith> | if we host the email archives we want it at the some domain, no? |
| 07:50 | <MikeSmith> | I know we could rewrite the URLs |
| 07:52 | <annevk> | MikeSmith: yeah, ideally everything the same |
| 07:52 | <annevk> | MikeSmith: since DreamHost doesn't provide us with HTTPS, lists.whatwg.org is basically broken |
| 07:55 | <MikeSmith> | well I could host something experimentally first, either under https://sideshowbarker.net/ or I get another domain and cert |
| 07:55 | <MikeSmith> | or we transfer DNS for some domain to a host I get set up |
| 07:56 | <MikeSmith> | or subdomain of what.org |
| 07:56 | <MikeSmith> | ah yeah, so if we could do that for lists.whatwg.org yeah |
| 07:57 | <MikeSmith> | but the other thing is, we'd want to decide on what e-mail archiving software we want to use |
| 07:57 | <annevk> | whatwg/wattsi no longer being a fork made that somewhat hard |
| 07:58 | <MikeSmith> | rather than the old-fashioned one we had before, and the mailman thing or whatever it is that we have a w3c |
| 07:58 | <annevk> | if we use different software we'd have to setup redirects and such, no? |
| 07:58 | <MikeSmith> | ah you mean for the existing archives too |
| 07:58 | <MikeSmith> | yeah we would I guess |
| 07:58 | <annevk> | sounds painful |
| 07:59 | <MikeSmith> | yeah |
| 07:59 | <annevk> | I'm not opposed, but I'm not sure how complicated you'd want to make this |
| 07:59 | <MikeSmith> | no, I didn't understand what the goal was |
| 07:59 | <annevk> | basically to get lists.whatwg.org on the HTTPS train |
| 08:00 | <MikeSmith> | if the goal is to make the existing URLs to the archive actually work again I can definitely host that |
| 08:00 | <MikeSmith> | yeah |
| 08:00 | <MikeSmith> | so that's do-able |
| 08:01 | <MikeSmith> | > annevk: whatwg/wattsi no longer being a fork made that somewhat hard |
| 08:01 | <MikeSmith> | but you got it worked out OK? |
| 08:01 | <annevk> | yeah, just deleted what I had and then did it again |
| 08:01 | <MikeSmith> | k |
| 08:02 | <MikeSmith> | anyway right my biggest priority is that I want to get the changes to the build script landed |
| 08:02 | <MikeSmith> | then I will return to greater sanity and can think clearly about other stuff |
| 08:04 | <MikeSmith> | spending a lot of time writing bash/shell script stuff kind of messes with one's mind |
| 08:04 | <annevk> | yeah, this has no priority whatsoever, just seemed like a good task to sort out first, since that is actually something that is broken with our current server setup |
| 08:04 | <MikeSmith> | yeah agreed |
| 08:05 | <MikeSmith> | it will be cheaper and simpler to deploy come November of course |
| 08:05 | <MikeSmith> | as far as the cert setup |
| 08:06 | <annevk> | MikeSmith: yeah, hopefully that works out well |
| 08:06 | <MikeSmith> | I think it will. They met their goal for this month and seem to be on track with the plans for Nov |
| 08:06 | <annevk> | MikeSmith: would be great if we could migrate 1H of next year to avoid having to do the dance again, certificate lasts until July 2016 or so |
| 08:06 | <MikeSmith> | ah yeah |
| 08:07 | <annevk> | And I somewhat doubt DreamHost will have Let's Encrypt integration anytime soon, but who knows |
| 08:07 | <MikeSmith> | ah true |
| 08:09 | <MikeSmith> | so about that, anyway in general, I do not find it painful or onerous to maintain a full system from a VM with root |
| 08:10 | <MikeSmith> | I've run my own sites that way for long years now, including running an MTA (exim4), which is about as hairy as it gets |
| 08:10 | <zcorpan> | annevk: hmmm, img-environment-changes should have initiator "imageset" probably |
| 08:11 | <MikeSmith> | so if/when were to decide to move away from Dreamhost to running it all on a VM I think it could be manageable and I would be OK taking responsiblity for keeping it running and dealing with outages and what-not |
| 08:11 | <annevk> | zcorpan: did I cause a regression? |
| 08:13 | <zcorpan> | annevk: no, the old text didn't mention it in that algorithm. i can file a new bug |
| 08:17 | <zcorpan> | https://github.com/whatwg/html/issues/159 |
| 08:17 | <annevk> | zcorpan: unless there's anything else I'll merge https://github.com/whatwg/html/commit/5ce1250e9832f2ae6fed4b6e8151a39be2a6dd78 into master |
| 08:18 | <zcorpan> | annevk: LGTM |
| 08:19 | <Ms2ger> | annevk, you'll have to close the issues manually, btw |
| 08:19 | <annevk> | Ms2ger: yeah I know |
| 08:20 | <MikeSmith> | annevk: I never made time to review it but will post-merge (on the off chance I notice something that nobody else noticed yet) |
| 08:23 | <annevk> | MikeSmith: thank you |
| 08:24 | <annevk> | MikeSmith: there is definitely things left to fix, in particular wording around response handling can be much improved still |
| 08:24 | <MikeSmith> | well for now it's really nice to have that landed |
| 08:31 | <annevk> | >23500 occurrences of "<code" |
| 08:31 | <annevk> | That makes annotating strings and byte sequences a little more involved than I hoped for |
| 08:45 | <Ms2ger> | Well this is not something I expected to see today: https://bugzilla.mozilla.org/show_bug.cgi?id=1205391 |
| 08:53 | <annevk> | Ms2ger: it's amusing how much senior engineers "spam" attracts |
| 09:08 | <annevk> | It seems Fetch can't escape the jokes: https://twitter.com/kevinmarks/status/644430480364802048 https://twitter.com/maybekatz/status/643690173486620672 |
| 09:08 | <annevk> | I'm not even sure whether I've seen that movie |
| 09:10 | <tantek> | annevk: it's a powerful reference |
| 09:13 | <JakeA> | I haven't seen it, but I feel like I have now |
| 09:40 | <annevk> | heycam|away: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28765 seems bogus, but I'm not sure... |
| 09:40 | <annevk> | heycam|away: do you know? |
| 09:40 | <annevk> | Ms2ger: you perhaps? |
| 09:42 | <jgraham> | Seems Ms2ger didn't want to help |
| 09:50 | <annevk> | :-( |
| 10:08 | <Ms2ger> | annevk, sup? |
| 10:15 | <Ms2ger> | annevk, seems like it could make sense if we're ever going to add more prefixed attributes to WorkerGlobalScope |
| 10:57 | <annevk> | Ms2ger: can you explain to me how they're different? |
| 10:59 | <Ms2ger> | annevk, how what's different? |
| 11:00 | <annevk> | Ms2ger: using implements vs inheritance for a global |
| 11:02 | <Ms2ger> | Inherited attributes aren't "own" |
| 11:03 | <Ms2ger> | So `var location = location` in a worker creates a shadowing own property initialized to undefined, and then sets it to itself |
| 11:06 | <annevk> | Ms2ger: https://heycam.github.io/webidl/#Global in step 2 it says consequential interfaces which includes inherited interfaces |
| 11:06 | <Ms2ger> | Really? |
| 11:07 | <Ms2ger> | I don't think A is a consequential interface of A |
| 11:08 | <annevk> | Ms2ger: yeah, I guess not, that seems somewhat confusing |
| 11:08 | <Ms2ger> | No opinion on whether it should |
| 12:26 | <annevk> | Ms2ger: do you know how Gecko's worker setup works? |
| 12:26 | <annevk> | Ms2ger: fixing the base URL thing is somewhat complicated since the specification sets up the environment before it actually starts fetching... |
| 12:27 | <Ms2ger> | annevk, vaguely. Have you seen khuey's presentation? |
| 12:28 | <annevk> | Ms2ger: I don't think it goes into this from memory, but it's been a while |
| 12:30 | <Ms2ger> | https://mxr.mozilla.org/mozilla-central/ident?i=GetOrCreateGlobalScope may point to related code? |
| 12:51 | <annevk> | http://www.w3.org/TR/workers/ o_O |
| 12:52 | <slvrbckt> | does anyone know if ReadableStream can be used to acheive what is described in this writeup? http://maxogden.com/a-proposal-for-streaming-xhr.html |
| 12:54 | <annevk> | slvrbckt: I think so, yes |
| 12:56 | <annevk> | I think I have a way to rewrite this worker thing... Not entirely sure it won't crash anything though |
| 12:58 | <slvrbckt> | annevk: I'm having a hard time finding any good documentation on using ReadableStream, do you know of any good introductions to using it with large file downloads in the browser? |
| 12:59 | <annevk> | slvrbckt: does https://jakearchibald.com/2015/thats-so-fetch/#streams help? |
| 13:04 | <slvrbckt> | annevk: that does help, it's centered about text data, but I think it shouldn't be too hard to translate that to dealing with binary data |
| 13:05 | <annevk> | Ms2ger: so the way Hixie designed this basically requires overwriting the URL of the setting object later on... |
| 13:06 | <annevk> | Ms2ger: since a MessagePort object needs to be associated with a settings object upon creation |
| 13:06 | <annevk> | Ms2ger: and presumably MessagePorts need to be entangled before being handed back |
| 13:06 | <annevk> | Ms2ger: so you would either have to try to unravel all that or do this quick hack... |
| 13:06 | <Ms2ger> | Ugh, MessagePorts |
| 13:07 | <annevk> | There's also a bug in the spec where it entangles the MessagePort with the global object rather than the settings object |
| 13:07 | <annevk> | That's why I thought I could fix it initially, by just creating the settings object later |
| 13:08 | <annevk> | MikeSmith: I think rigo just advertized self-signed certificates on public-webappsec... |
| 13:08 | <annevk> | mkwst: will that list get moderation at some point? |
| 13:41 | <annevk> | Ms2ger: so... shared workers and redirects, how does that work? |
| 13:41 | <annevk> | Ms2ger: each time I get close to solving this, another problem pops up |
| 13:45 | <wanderview> | annevk: what kind of redirects? worker scripts are restricted to same-origin, right? |
| 13:45 | <annevk> | wanderview: sure |
| 13:46 | <annevk> | wanderview: say you have /a/ redirecting to /b/, what is the base URL? |
| 13:46 | <annevk> | wanderview: what does new SharedWorker("/a/") vs new SharedWorker("/b/") do (and combinations on that theme) |
| 13:46 | <wanderview> | hmm, ok |
| 13:47 | <annevk> | Not really, it all looks ind of broken :-) |
| 13:48 | <Ms2ger> | annevk, yeah |
| 13:49 | <Ms2ger> | Let me quote from my lists of things to write tests for |
| 13:49 | <Ms2ger> | SharedWorker |
| 13:49 | <Ms2ger> | > If worker global scope's location attribute represents an absolute URL |
| 13:49 | <Ms2ger> | > that is not exactly equal to scriptURL, then throw a URLMismatchError |
| 13:49 | <Ms2ger> | > exception and abort all these steps. |
| 13:49 | <Ms2ger> | new SharedWorker("x"); new SharedWorker("x"); with x redirecting to y |
| 13:50 | <annevk> | Ms2ger: the whole WorkerLocation concept is kind of hand wavy designed too |
| 13:51 | <Ms2ger> | It does mention "after redirects", though, doesn't it? |
| 13:51 | <annevk> | Ms2ger: sure, but nowhere is it actually set |
| 13:51 | <Ms2ger> | Yeah |
| 13:51 | <Ms2ger> | Par for the course :) |
| 14:03 | <annevk> | Ms2ger: it seems you get distinct instances https://dump.testsuite.org/worker/sharedworker.html |
| 14:03 | <Ms2ger> | Lovely |
| 14:03 | <Ms2ger> | Not very surprising, but still |
| 14:03 | <annevk> | Ms2ger: maybe I should wait creating a new one until I get something back, see what happens then |
| 14:04 | <Ms2ger> | Ugh, hadn't even though about that |
| 14:18 | <annevk> | Ms2ger: doesn't seem to matter |
| 14:20 | <annevk> | Ms2ger: how can you even get a URLMismatchError? |
| 14:24 | <annevk> | Ah, through the name property |
| 14:25 | <ccardona-work> | Good morning/afternoon/evening WHATWG crew o/ |
| 14:32 | <Ms2ger> | I wonder if we should just pull in the WebSocket API spec |
| 14:32 | <annevk> | Ms2ger: you mean protocol? |
| 14:33 | <Ms2ger> | I can't type |
| 14:33 | <Ms2ger> | Yes |
| 14:34 | <annevk> | So Chromium does use the URLMismatchError, Gecko just keeps spawning workers |
| 14:34 | <annevk> | https://dump.testsuite.org/worker/sharedworker-name.html |
| 14:34 | <annevk> | I thought we had tests for this stuff? |
| 14:34 | <Ms2ger> | Chrome supports SharedWorker? |
| 14:34 | <annevk> | (Mind you, Chromium only does it when the name property is used.) |
| 14:34 | <annevk> | Yes |
| 14:39 | <annevk> | But Chrome does key on the "scriptURL", not the final URL |
| 14:39 | <annevk> | So that location attribute mess has to go |
| 14:43 | <annevk> | Ms2ger: what does Servo do? |
| 14:44 | <Ms2ger> | We don't have SharedWorkers |
| 14:44 | <annevk> | I don't think I can make the PR for this today :-/ But I'll try to write something up tomorrow |
| 14:44 | <Ms2ger> | Also no script settings stuff |
| 14:44 | <annevk> | I have an alternate solution for the environment settings object stuff |
| 14:44 | <Ms2ger> | Sounds good :) |
| 14:45 | <annevk> | Just have the environment settings object's API base URL and creation URL return some internal slot from the global |
| 14:45 | <Ms2ger> | Hmm |
| 15:35 | wanderview | is trying to remember why we don't want the page URL to update when a navigation is intercepted by a SW. |
| 15:52 | <JakeA> | wanderview: because I might respond with caches.match('/static/page-shell-7bfab2c.html') |
| 15:53 | <JakeA> | This is what https://wiki-offline.jakearchibald.com/ does |
| 15:54 | <JakeA> | https://github.com/jakearchibald/offline-wikipedia/blob/master/public/js/sw/index.js#L82 |
| 15:54 | <wanderview> | JakeA: you could make that a synthetic response with no Response.url |
| 15:55 | <JakeA> | wanderview: I could… but it's a bit messy |
| 15:56 | <JakeA> | Either I get shell from the cache, read the text & create a new reponse with it - which loses streaming |
| 15:56 | <JakeA> | Or at install time, I fetch the shell, read it as text, and construct a new response with it to cache |
| 15:57 | <wanderview> | hmm |
| 15:58 | <wanderview> | JakeA: well, I guess thats not the case I was thinking of... I was thinking of allowing opaque responses but making the page URL update |
| 15:58 | <wanderview> | instead of rejecting opaque responses |
| 15:59 | <JakeA> | wanderview: Allowing opaque responses breaks SOP one way or another |
| 15:59 | <JakeA> | If I retain control of the page, I now hear about requests I shouldn't be able to hear about |
| 16:00 | <JakeA> | If I don't retain control, that's just a redirect isn't it? |
| 16:00 | <wanderview> | JakeA: how is updating the navigation final URL to match the opaque response URL different from a navigation following no-cors cross origin redirects? |
| 16:00 | <wanderview> | I guess I'm asking why we can't treat it like a redirect |
| 16:01 | <wanderview> | I guess I'm just annoyed because the special cases for navigations keep changing: https://github.com/whatwg/fetch/issues/126 |
| 16:19 | <JakeA> | wanderview: As in, fetch would generate a redirect to the opaqueResponse.url, then that would go up to the navigate level, change the browser url, then call fetch, which would respond with the opaqueResponse again but unopaqued because the origin is now the same? |
| 16:20 | <jtcranmer> | annevk: fwiw, I did finally implement most of UTS #46 in JS |
| 16:21 | <Ms2ger> | Now do the same in Rust |
| 16:21 | <wanderview> | JakeA: as in the navigation algorithm in http would act as if it had already been redirected Response.url when given an opaque response |
| 16:22 | <JakeA> | wanderview: but it would only do this for opaque responses, or all responses? |
| 16:22 | <wanderview> | JakeA: ignoring the navigation part here... this is in fact how we plan to implement opaque response tainting in gecko |
| 16:22 | <jtcranmer> | Ms2ger: no, because I suspect the people who work on Servo would want support for the bidi and contextual rules and I don't want to touch those with a 20 perch pole |
| 16:22 | <wanderview> | JakeA: well, I was originally suggesting for all responses, but I guess it could just do it for opaque responses... if we defined opaque response tainting like this in general |
| 16:23 | <annevk> | jtcranmer: I saw, haven't had time to look at it, but cool |
| 16:26 | <JakeA> | wanderview: it seems weird for a non-redirect response to become a redirect… what does this improve? |
| 16:26 | <jtcranmer> | annevk: it even passes the IDNA test vector suite! well, except for all the tests that require bidi/contextual to be an error |
| 16:26 | <jtcranmer> | (and, to be fair, those are the tests where UTS #46 is not following the RFC) |
| 16:27 | <wanderview> | JakeA: it lets us keep the simple "opaque responses are ok for no-cors requests" and lets use make navigations "no-cors" requests |
| 16:29 | <JakeA> | I haven't gotten my head around the navigation no-cors thing yet |
| 16:30 | <wanderview> | I dislike having special extra rules for navigations that developers have to be aware of... |
| 16:30 | <wanderview> | we should express the difference in navigations in the primitives we've defined... or come up with better primitives |
| 16:32 | <JakeA> | I agree with that, but opaque responses turning into redirects for navigations seems like a specialer rule than "navigation responses cannot be opaque" |
| 16:34 | <wanderview> | JakeA: I guess I would find it easier to express if we had a no-cors-navigation RequestMode |
| 16:35 | <annevk> | wanderview: can't you infer this from request's destination? |
| 16:37 | <wanderview> | annevk: maybe, but how many attributes to we expect developers to check? |
| 16:38 | <wanderview> | JakeA: annevk: more realistically, do we expect this to work for navigations? e.respondWith(fetch(e.request)) |
| 16:38 | <wanderview> | because its not going to if e.request.url is cross origin |
| 16:38 | <JakeA> | That won't happen |
| 16:38 | <wanderview> | JakeA: it won't? why not? |
| 16:38 | <JakeA> | If it's a cross origin navigation it'll go to the SW for the scope on the destination origin |
| 16:39 | <annevk> | right |
| 16:40 | <annevk> | MikeSmith: btw, sorry for not asking earlier, but are you looking for help with the whatwg/html-build PRs? |
| 16:40 | <annevk> | MikeSmith: I'm not great with shell, but I can test stuff... |
| 16:43 | <wanderview> | ok |
| 16:44 | <wanderview> | JakeA: annevk: I guess the problem I am struggling with is RequestMode seems to be acting as our security policy... and but we're polluting that by making it conditional on another attribute |
| 16:44 | <jamesr___> | anyone know the history of navigator.productSub ? |
| 16:45 | <wanderview> | but I give up |
| 16:45 | <jamesr___> | https://html.spec.whatwg.org/multipage/webappapis.html#the-navigator-object lists navigator.product as the constant "Gecko" but doesn't say productsub |
| 16:45 | <annevk> | wanderview: you would prefer mode = navigate? |
| 16:45 | <annevk> | wanderview: note that we already had a check for navigation requests |
| 16:46 | <annevk> | wanderview: for "opaqueredirect" |
| 16:46 | <wanderview> | annevk: I know... that seems unnecessary though... why block fetch() from getting opaqueredirect? |
| 16:46 | <jamesr___> | in my chrome navigator.productSub is "20030107" and in my firefox it is "20100101" |
| 16:46 | <annevk> | wanderview: sigh, I thought we discussed that? |
| 16:46 | <annevk> | It would take me a while to remember the arguments again... |
| 16:47 | <wanderview> | annevk: we did... i thought you said "better to be conservative for now" |
| 16:47 | <annevk> | wanderview: I thought I also pointed out some issues |
| 16:47 | <annevk> | wanderview: like the fact that you can't reenter the SW after seeing such a response |
| 16:48 | <annevk> | wanderview: which would be inconsistent with other redirects you get from the SW |
| 16:48 | <wanderview> | annevk: I would prefer a different RequestMode to express the specialness of navigations |
| 16:48 | <annevk> | wanderview: anyway, a mode = navigate could handle both of those |
| 16:49 | <annevk> | JakeA: what do you think? ^^ |
| 16:49 | <wanderview> | I have to go get lunch |
| 16:49 | <annevk> | jamesr___: "productSub: Mozilla and Safari only; returns same as buildID in Mozilla, and returns the fixed string "20030107" in Safari" is what a comment says in the source |
| 16:49 | <wanderview> | maybe I will be less whiny after eating |
| 16:50 | <annevk> | jamesr___: I guess Gecko picked a different time to freeze it |
| 16:52 | <annevk> | TabAtkins: UI Events taking over EventTarget et al is back :-( |
| 16:54 | <MikeSmith> | annevk: there's no rush on those build PRs. I'm happy just waiting til Domenic has time again |
| 16:54 | <MikeSmith> | actually one of them is waiting on me to push changes from the first round of review |
| 16:55 | <jamesr___> | annevk: pretty sure chrome inherited that string from webkit |
| 16:55 | <annevk> | jamesr___: yeah looks like it |
| 16:55 | <jamesr___> | why does this string exist at all? is something required by web compat? |
| 16:55 | <jamesr___> | what do edge/IE return? |
| 16:55 | <annevk> | jamesr___: I don't know |
| 16:59 | <annevk> | MikeSmith: okidoki |
| 16:59 | <annevk> | jamesr___: if you find out, you can PR the spec :-) |
| 17:02 | <JakeA> | annevk: I'm not against a navigate mode… but I'm not really sure we need it |
| 17:03 | <annevk> | JakeA: I guess the rationale is that the security story is somewhat cleaner, but it's rather edge case-y |
| 17:04 | <annevk> | JakeA: I do think it makes sense conceptually |
| 17:05 | <JakeA> | annevk: happy to go for it then |
| 17:12 | <JakeA> | annevk: what does it mean to make a mode:navigate request with redirect:follow? |
| 17:12 | <annevk> | JakeA: you wouldn't be able to create them |
| 17:13 | <JakeA> | that's fair |
| 17:14 | <wanderview> | annevk: another annoyance of mine with opaqueredirect check on navigate... we allow fetch(url, { redirect: "manual" }), but that will break if its intercepted by a sw that does e.respondWith(fetch(e.request)) |
| 17:15 | <wanderview> | in that case I would expect the outer fetch() to get the opaqueredirect as well |
| 17:18 | <annevk> | wanderview: hmm, I guess we could make that particular check conditional on redirect mode instead |
| 17:18 | <annevk> | wanderview: as long as your redirect mode is manual, you'll be able to get an opaqueredirect |
| 17:18 | <JakeA> | ohhh I thought that's how it worked |
| 17:18 | <wanderview> | annevk: that would be most excellent |
| 17:18 | <annevk> | wanderview: file an issue? |
| 17:18 | <wanderview> | sure |
| 17:22 | <wanderview> | https://github.com/whatwg/fetch/issues/127 |
| 17:32 | <Domenic> | Hmm the images URLs change hasn't made it to the spec |
| 17:33 | <annevk> | Domenic: did you update the server copy of wattsi? |
| 17:33 | <Domenic> | annevk: it should auto-update |
| 17:34 | <annevk> | Domenic: ah, maybe it's broken just like my local copy because the GitHub thing is no longer a fork? |
| 17:34 | <Domenic> | annevk: that would be surprising... but maybe |
| 17:34 | <annevk> | Domenic: I couldn't update whatwg/wattsi earlier today; kept complaining |
| 17:35 | <annevk> | Domenic: ended up removing it and just fetching it anew |
| 17:35 | <Domenic> | I haven't had any problems, hmm |
| 17:35 | <annevk> | Domenic: maybe it's the GitHub client that was the problem... |
| 17:35 | <Domenic> | At least the whatwg/html changes are still making it in, so the build is not breaking... |
| 17:35 | <Domenic> | I really should set up some sort of email for if the build breaks |
| 17:36 | <Domenic> | Of course then I start wondering about setting up a whole proper CI server thingy |
| 17:36 | <annevk> | Oh the server doesn't use git |
| 17:36 | <annevk> | It just fetches a zip |
| 17:37 | <Domenic> | it probably should though, the zip thing is a bit convoluted |
| 18:16 | <beverloo> | annevk, sicking, do notifications in Firefox close when you click on them? |
| 18:16 | <sicking> | don't know |
| 18:16 | <sicking> | sorry |
| 18:17 | <sicking> | not been involved with the desktop side |
| 18:17 | <beverloo> | ok, they seem to on Linux, but I need to test whether the onclose event fires as well |
| 18:43 | <TabAtkins> | annevk: Investigating |
| 19:05 | <annevk> | beverloo: not on OS X |
| 19:05 | <annevk> | beverloo: close fires when you dismiss them from the notification center |
| 19:06 | <annevk> | beverloo: also, seems to require two clicks before click fires |
| 19:15 | <zcorpan> | annevk: i don't understand your concern in https://www.w3.org/Bugs/Public/show_bug.cgi?id=26024 |
| 19:33 | <annevk> | zcorpan: say e.g., you use <img src=https://www.google.com/>; on example.com; a drag & drop should not reveal what google.com redirected too, that violates SOP |
| 19:34 | <zcorpan> | annevk: ah ok. currentSrc only gives the resolved URL before redirects |
| 19:34 | <annevk> | zcorpan: if it's just one of the URLs from the markup that's fine |
| 19:35 | <zcorpan> | yeah |
| 19:45 | <Krinkle> | Ah that reminds me of an attack from a few years ago involving flash, invisible iframes and a simple "slide to unlock" kind of game drawn on top. |
| 19:45 | <Krinkle> | Users weren't aware of what they were doing. |
| 19:46 | <Krinkle> | I forget what it was but it was something but hotmail redirecting to a session subdomain. |
| 19:46 | <Krinkle> | if logged in |