| 00:54 | <wanderview> | JakeA: also, I think this spec issue might be another one of those things we "decided", but neither firefox or chrome ships yet: https://github.com/w3c/ServiceWorker/issues/787 |
| 00:54 | <wanderview> | JakeA: do we really want to do that or should we warn MS/webkit off from it? |
| 06:45 | <zcorpan> | gsnedders: https://whatwg.org/specs/web-forms/2005-07-03/ |
| 06:57 | <zcorpan> | https://annevankesteren.nl/2005/07/html5-doctype is a good read; annevk's way of rambling, and the comments with sgml nerd snipes |
| 07:14 | <MikeSmith> | wow I think I never read that before maybe |
| 07:18 | <MikeSmith> | fun to look at https://annevankesteren.nl/2005/06/countdown |
| 07:21 | <MikeSmith> | and https://annevankesteren.nl/2003/08/markup |
| 07:36 | <ondras> | reading about the "noopener" stuff |
| 07:37 | <ondras> | apparently the attack vector is also relevant to <form target="_blank"> ? |
| 07:37 | <ondras> | but there is no rel attribute here to prevent it from happening? |
| 07:41 | <MikeSmith> | hmm yeah |
| 07:42 | <MikeSmith> | I wonder if mathiasbynens has written about this |
| 07:43 | <mathiasbynens> | not about <form target="_blank"> specifically (only https://mathiasbynens.github.io/rel-noopener/) |
| 07:43 | <MikeSmith> | hi mathiasbynens |
| 07:43 | mathiasbynens | wonders how common <form target=_blank> is |
| 07:43 | <mathiasbynens> | heya MikeSmith! |
| 07:43 | <MikeSmith> | yeah, I knew about https://mathiasbynens.github.io/rel-noopener/ |
| 07:44 | <MikeSmith> | I find https://stackoverflow.com/questions/13569776/obtain-reference-to-blank-target-window-on-form-submit |
| 07:45 | <ondras> | mathiasbynens: probably not that common, but once people start adding noopeners to <a>s, attackers might switch to these forms |
| 07:46 | <MikeSmith> | Domenic: by the way, does the Stack Overflow stats info expose stats at the question level? Such that you could look at a particular question and find out where the views of that question are coming from? |
| 07:47 | <Domenic> | MikeSmith: not that I know of, hmm |
| 07:58 | <annevk> | ondras: I don't think the worry is attackers injecting the links |
| 07:58 | <ondras> | ok |
| 07:58 | <ondras> | (but attackers manipulating the target pages, right?) |
| 07:58 | <annevk> | ondras: it is worth considering though how much of the stuff that works on <a> should also work on <form> |
| 07:59 | <annevk> | ondras: since they're effectively the same and end up triggering the same algorithm |
| 07:59 | <ondras> | right |
| 07:59 | <annevk> | ondras: adding rel="" to <form> doesn't seem bad per se |
| 08:02 | <ondras> | annevk: agreed |
| 08:03 | <ondras> | annevk: also, perhaps, <base>, as these can specify target="_blank" as well |
| 08:04 | <annevk> | ondras: I'd rather people just avoid <base> |
| 08:04 | <ondras> | :) |
| 08:04 | ondras | has a use case |
| 08:05 | <annevk> | Of course you do |
| 08:05 | <ondras> | my html slide decks typically have <base target="_blank"> and I think it is reasonable |
| 08:05 | <annevk> | Yeah, I guess <base rel=noopener> would actually be nice |
| 08:06 | <ondras> | :) |
| 08:06 | <annevk> | ondras: you might be able to convince mkwst and make this a thing |
| 08:06 | <ondras> | annevk: okay. I shall talk him to <form rel> or <base rel> or both? |
| 08:10 | <annevk> | ondras: both I suppose |
| 08:10 | <ondras> | annevk: okay, thanks |
| 10:04 | <ondras> | mkwst: what is your opinion regarding the possibility of adding the rel=noopener attribute/value for <form> and <base> tags? |
| 10:06 | <JakeA> | wanderview: Baku was right in terms of the signal null thing. It was just the IDL that was wrong. Fixing now. |
| 10:07 | <JakeA> | done |
| 11:38 | <ondras> | so, for an Atomics-related question, who is the best irc-enabled person? |
| 11:44 | <annevk> | ondras: maybe in #tc39 or #jslang on Mozilla IRC? |
| 11:44 | <annevk> | (#tc39 is on Freenode) |
| 11:45 | <annevk> | ondras: as for adding rel to <form> and <base>, might be better to file a bug against whatwg/html and get attention that way |
| 11:45 | <annevk> | ondras: I vaguely recall someone suggesting it before for <form> |
| 11:46 | <ondras> | annevk: okay, thanks |
| 12:25 | <JakeA> | annevk: any idea why XHR terminates the request during the open() method? https://xhr.spec.whatwg.org/#the-open()-method |
| 12:25 | <JakeA> | step 10 |
| 12:30 | <JakeA> | can an XHR be opened, sent, then opened again (resulting in termination of the original) |
| 12:54 | <Ms2ger> | JakeA, why not? |
| 13:06 | <JakeA> | Ms2ger: I guess I'd always thought that new XMLHttpRequest maps to at most one request/response |
| 13:07 | <Ms2ger> | Now that would be the simple approach |
| 13:08 | <Ms2ger> | But imagine the overhead if you had to create a new object for your next request! |
| 13:08 | <Ms2ger> | (At least I suspect that was the idea) |
| 13:08 | <JakeA> | hmm |
| 13:10 | <zcorpan> | how's w3schools these days, for the purpose of being worthwhile for beginners? has it improved? i see http://www.w3fools.com/ has toned down its messaging from what i remember |
| 13:10 | <TimothyGu> | JakeA: just making sure, you did see my (mostly inconsequential) comment on that fetch cancelation PR right? |
| 13:11 | <JakeA> | TimothyGu: yep! I've made the changes, just haven't pushed yet |
| 13:11 | <JakeA> | Was OOO last week |
| 13:11 | <TimothyGu> | oh cool |
| 13:18 | <annevk> | JakeA: I'm not sure who made all the dubious decisions in the XMLHttpRequest API |
| 13:20 | <MikeSmith> | I thought Microsoft did and everybody else just had to reverse engineer the IE behavior |
| 13:21 | <MikeSmith> | zcorpan: I haven’t seen any indications that w3cschools has improved at all |
| 13:21 | <MikeSmith> | they have no incentive to improve really |
| 13:22 | <annevk> | MikeSmith: the module might have come from Outlook originally or some such |
| 13:23 | <MikeSmith> | yeah it did |
| 13:23 | <MikeSmith> | different team |
| 13:23 | <annevk> | MikeSmith: there was a post by a Microsoft engineer at some point, but nobody really wanted to come out say it was the truth |
| 13:24 | <zcorpan> | MikeSmith: "W3Schools still has issues but they have at least worked on the primary concern developers had." says w3fools, which seems like an indicator of improvement |
| 13:24 | <JakeA> | TimothyGu: thanks for the review btw! |
| 13:24 | <TimothyGu> | JakeA: np :) |
| 13:25 | <MikeSmith> | we met the guy who worked on the team that made XHR, when we went to Redmond for that sorta emergency meeting after Microsoft released their proprietary CORS thing |
| 13:25 | <gsnedders> | zcorpan: https://github.com/paulirish/w3fools/commit/0d78c7fe164418937695b7f20cd536a910760060 |
| 13:25 | <MikeSmith> | zcorpan: I don’t think it’s observable that it’s improved |
| 13:26 | <zcorpan> | k, thanks |
| 13:26 | <MikeSmith> | at least I can say from reading questions at Stack Overflow that there are many cases still of content there which is out of date or plain wrong |
| 13:27 | <gsnedders> | zcorpan: thugh obviously that commit that doesn't say what changed |
| 13:28 | <MikeSmith> | http://www.hixie.ch/advocacy/writing-test-cases-for-web-browsers is a nice read (found by way of link in one of annevk old blog posts) |
| 13:29 | <MikeSmith> | I especially like STEP ONE of Creating testcases from scratch |
| 13:29 | <MikeSmith> | the advice on reading the specification |
| 13:29 | <wanderview> | JakeA: should baku write a github issue for the AbortSignal? thing? |
| 13:34 | <JakeA> | wanderview: I just pushed that change |
| 13:35 | <wanderview> | JakeA: thanks |
| 13:44 | <wanderview> | JakeA: I wonder what edge implemented here... |
| 13:44 | <JakeA> | wanderview: yeah, I'll ping them once the PR lands |
| 13:58 | <JakeA> | annevk: GitHub isn't displaying it on the main pull page for some reason, but I'm not sure what the best way forward is in terms of abort & XHR https://github.com/whatwg/fetch/pull/523/files#r136062170 |
| 14:00 | <Ms2ger> | MikeSmith, yeah, good advice |
| 14:00 | Ms2ger | skips the spec-reading part (boooooooooring), writes a test that vaguely matches what he thinks the spec might say |
| 14:03 | <annevk> | JakeA: I will look tomorrow most likely, sorry about that |
| 14:03 | <JakeA> | annevk: no problem at all |
| 14:05 | <wanderview> | JakeA: oh, here is a tricky question... if a FetchEvent handler saves the evt.request.signal somewhere, but does *not* call respondWith(), should the signal still fire if the outer network request is aborted? |
| 14:06 | <wanderview> | JakeA: or can we mark disconnect the signal after the FetchEvent handler passes on intercepting the request |
| 14:06 | <wanderview> | ? |
| 14:09 | <JakeA> | wanderview: that is a tricky question. I'm guessing it's much easier implementation-wise to disconnect the signal? |
| 14:10 | <wanderview> | JakeA: easier... not really... but from an efficiency and memory footprint it would be nice to |
| 14:10 | <wanderview> | to do |
| 14:12 | <wanderview> | JakeA: I guess there is a related question... if the event handler does not call respondWith(), but holds on to FetchEvent.request... can it read the body later? or is the body marked used when the browser conceptually consumes it? |
| 14:17 | <JakeA> | wanderview: body should be marked as used |
| 14:18 | <JakeA> | I think |
| 14:18 | <nox> | annevk: Did we stop trying to get every interface to have a Exposed attribute and kill PrimaryGlobal? |
| 14:19 | <wanderview> | JakeA: hmm... I doubt we do that |
| 14:19 | <JakeA> | wanderview: I haven't found it in the spec yet either |
| 14:21 | <Ms2ger> | nox, that has recently started happening |
| 14:21 | <Ms2ger> | https://github.com/heycam/webidl/pull/423 |
| 14:23 | <JakeA> | wanderview: hmm. It does feel like we're treating the request as a clone, which is especially broken in the body stream case |
| 14:23 | <JakeA> | wanderview: I'll write up an issue |
| 14:24 | <wanderview> | JakeA: in our implementation it is effectively a clone |
| 14:24 | <wanderview> | but not sure the spec should assume that |
| 14:31 | <ato> | annevk: What’s the right way to compare documents? |
| 14:32 | <ato> | annevk: Say I want to compare an element’s node document with the document of the WindowProxy? |
| 14:32 | <ato> | annevk: In specalese, that is. |
| 14:38 | <annevk> | nox: no |
| 14:39 | <annevk> | ato: doc is otherDoc? |
| 14:39 | <ato> | annevk: Just “is”? |
| 14:39 | <ato> | annevk: That’s super, thanks. |
| 14:56 | <JakeA> | wanderview: https://github.com/w3c/ServiceWorker/issues/1191 |
| 14:57 | <JakeA> | wanderview: It feels like request.signal should continue to work until it's GC'd |
| 14:59 | <tobie> | wanderview/gsnedders: re: adding comments to tests about what it is they're testing, that's what the name of the test is for. Which is why it is absurd that it's the last arg instead of the first. |
| 14:59 | <annevk> | ato: object identity is is |
| 14:59 | <wanderview> | tobie: a single string is pretty inadequate for documentation, imo |
| 14:59 | <gsnedders> | tobie: I agree with that now. Unfortunately, I didn't agree it when I originally reviewed testharness.js. :P |
| 14:59 | <tobie> | wanderview: means you're testing too many things at once, then. |
| 15:00 | <tobie> | gsnedders: rwaldron had a fit over this |
| 15:00 | <wanderview> | tobie: no it doesn't... please come write some service workers tests and get back to me |
| 15:00 | <wanderview> | and putting multi-line paragraphs in the name make it hard to write things like expectation files where you need to reference the test |
| 15:02 | <tobie> | wanderview: yeah, this might very well not be the right solution for all the cases, but it clearly is for the 80% and yet… |
| 15:02 | <tobie> | wanderview: good point re the need to ref tests by name in acceptance tests. |
| 15:03 | <tobie> | wanderview: care to point me to some good examples of SW tests? curious as to what they look like |
| 15:05 | <tobie> | wanderview: (in case that wasn't clear, that was a general "you", not you specifically) |
| 15:06 | <wanderview> | ok |
| 15:16 | <annevk> | JakeA: you mean until request can be GC'd, right? |
| 15:16 | <annevk> | JakeA: request has a strong reference to any objects it holds |
| 15:19 | <wanderview> | annevk: in theory someone could hold the signal alive beyond the end of the Request |
| 15:20 | <annevk> | wanderview: in that case it seems fine to toss the request though |
| 15:21 | <wanderview> | annevk: I guess I don't know what you are saying... even if the Request wrapper is GC'd, the signal tied to the main thread request could still work, right? |
| 15:22 | <annevk> | wanderview: I was mostly saying that request.signal should continue working for as long as someone has a reference to request |
| 15:29 | <JakeA> | agreed |
| 15:29 | <JakeA> | signal can't be gc'd until request is |
| 15:30 | <wanderview> | JakeA: also I think FetchEvent.request might need to be a "clone" because of cross-thread stuff |
| 15:32 | <JakeA> | wanderview: hm, so we'd need to buffer any request body stream until fetchEvent.request can be GC'd? |
| 15:32 | <wanderview> | JakeA: well, it might depend on how ReadableStream transfer is spec'd? is that spec'd yet? |
| 15:34 | <JakeA> | wanderview: nah, don't think so |
| 15:35 | <wanderview> | JakeA: in theory it should be like the browser consuming the Request.body stream on the main thread... it may stop reading if the worker thread is not consuming it, though |
| 15:57 | <ato> | annevk: Thanks |
| 16:21 | <wanderview> | JakeA: btw, current firefox nightly has abortable fetch enabled |
| 16:21 | <wanderview> | won't ride the trains to beta/release until we can fix the service worker FetchEvent.request.signal thing |
| 16:59 | <JakeA> | wanderview: ohhhh exciting! |
| 16:59 | <wanderview> | JakeA: I'm trying to make a glitch demo for it now |
| 17:03 | <wanderview> | JakeA: https://simple-abort-fetch.glitch.me/ |
| 17:05 | <wanderview> | I'm not sure why we buffer for so long before returning the Response |
| 17:16 | <wanderview> | JakeA: do you know how to set headers on responses in glitch server.js? I can't seem to make it work |
| 17:18 | <wanderview> | nevermind... I finally figured it out |
| 18:00 | <wanderview> | oh my https://webkit.org/blog/7846/concurrent-javascript-it-can-work/ |
| 20:16 | <smaug____> | that is scary |