| 00:08 | <jugglinmike> | Hello all. I have a question about Service Workers, if anyone here has a moment. |
| 00:08 | <jugglinmike> | If I understand correctly, it seems like the allocation of distinct task queues is implementation-defined |
| 00:09 | <jugglinmike> | So does that mean that one browser could implement postMessage and fetch tasks on the same queue, but another could define separate task queues for each? |
| 00:26 | <Mek> | jugglinmike: the spec defines separate task sources for fetch events and all other events, and additionally allows all those other event types to have their own task source per event type, yes. It is then also up to user agents how to map task sources to task queues (i.e. all events from the same task source end up in the same queue, but different sources might or might not share queues) |
| 00:55 | <Mek> | huh, http://output.jsbin.com/gasinavezo for some reason seems to output "true, false, true" in firefox, while unless I'm crazy and don't understand javascript all three checks should be identical... |
| 00:56 | <jugglinmike> | thank you Mek! |
| 00:59 | <Mek> | or wait, maybe in my case the problem is that the about:blank iframe hasn't finished loading yet in the first assignment, so my bug rather than soms craziness |
| 05:05 | <annevk> | Mek: within an event loop you can have multiple sources, but only one task loop |
| 05:05 | <annevk> | Mek: you can just give priority to a source |
| 07:12 | <MikeSmith> | annevk: so I spend my entire Stackoverflow time budget today on trying to answer one question: |
| 07:12 | <MikeSmith> | http://stackoverflow.com/questions/42239643/when-does-firefox-set-the-origin-header-to-null-in-post-requests/42242802#42242802 |
| 07:13 | <MikeSmith> | when you have time, as usual if I got anything wrong please either lemme know or comment/answer there |
| 07:14 | <MikeSmith> | I wrote all that without answering the one question the OP cares about most, which is I guess, Why Firefox doesn’t send Origin for cross-origin POSTs |
| 07:15 | <MikeSmith> | which I don’t know why Firefox does that, but if it does, it’s non-conforming, right? |
| 07:22 | <annevk> | Known bug in Fx |
| 07:23 | <annevk> | Will look when I get back |
| 08:10 | <annevk> | zcorpan: hmm https://bugzilla.mozilla.org/show_bug.cgi?id=1338535 |
| 08:11 | <zcorpan> | annevk: you get to decide if mozilla is interested in solving this problem? :-) |
| 08:14 | <zcorpan> | https://bugs.chromium.org/p/chromium/issues/detail?id=690927 is the issue for chromium |
| 08:14 | <annevk> | zcorpan: well, I'm not, not sure about Mozilla |
| 08:14 | <annevk> | zcorpan: but yeah, seems like my manager thought that would be a good idea |
| 08:15 | <annevk> | zcorpan: disabled does submit right? Why can't disabled be used everywhere? |
| 08:16 | <zcorpan> | annevk: it doesn't submit |
| 08:16 | <annevk> | zcorpan: oh okay, disabled means you can't copy I guess |
| 08:16 | <annevk> | It's been like a decade since I looked at forms closely, I know nothing |
| 08:17 | <zcorpan> | annevk: disabled can be used for all controls, but not readonly |
| 08:18 | <annevk> | MikeSmith: your answer is slightly wrong |
| 08:18 | <annevk> | MikeSmith: we changed when Origin is required to be transmitted recently |
| 08:19 | <annevk> | MikeSmith: to be either for cross-origin CORS (not same-origin) or requests whose method is not GET/HEAD |
| 08:19 | <annevk> | MikeSmith: so same-origin POST used to be excluded, but is no longer |
| 08:19 | <annevk> | MikeSmith: cross-origin POST from a <form> (without CORS) used to be excluded, but is no longer |
| 08:20 | <annevk> | MikeSmith: therefore the behavior in Fx is considered a bug |
| 08:23 | <MikeSmith> | annevk: OK I thought my answer had the current state of things right at least, but I you mean I should update the answer to indicate that the behavior changed recently? (and note what the previous required behavior was) |
| 08:24 | <annevk> | MikeSmith: up to you I suppose, but see https://github.com/whatwg/fetch/commit/eb89fcd54bb39e81b11c569f6ad7ba615883f7b9 for the change |
| 08:25 | <MikeSmith> | OK, I guess this is another case where browsers have not caught up with the spec change yet? |
| 08:32 | <annevk> | MikeSmith: well, Chrome always implemented that behavior and WebKit too, but it never got into Firefox |
| 08:32 | <annevk> | MikeSmith: it's something Adam Barth pushed but it never really got standardized/accepted |
| 08:32 | <annevk> | And I kinda dislike it since it no longer makes CORS requests distinct |
| 08:35 | <MikeSmith> | yeah |
| 08:36 | <MikeSmith> | it’s also more confusing for authors/developers |
| 08:37 | <MikeSmith> | anyway I updated my SO answer: |
| 08:37 | <othermaciej> | annevk, zcorpan: for non-text controls like checkboxes or radio buttons, it's confusing to have it be read-only but not have the disabled appearance, and is generally not done in native toolkits. So original idea of extending readonly was bad. The submitanyway idea isn't broken u-wise but it seems super marginal, based on the stated use case. It's basically a conenience for something really rare. |
| 08:37 | <MikeSmith> | Note: The above describes how the Fetch spec currently defines the requirements, due to a change that was made to the spec on 2016-12-09. Up until then the requirements were different: |
| 08:37 | <MikeSmith> | previously no Origin was sent for a same-origin POST |
| 08:37 | <MikeSmith> | previously no Origin was sent for cross-origin POST from a <form> (without CORS) |
| 08:37 | <MikeSmith> | So I think the Firefox behavior described in the question conforms to what the spec previously required, but not what the spec currently requires. |
| 08:37 | <MikeSmith> | hey othermaciej! |
| 08:38 | <othermaciej> | Also don't like the guy saying "WHATWG agrees to standardize", that doesn't seem a fair representation of discussion of the issue |
| 08:38 | <othermaciej> | Hi MikeSmith! |
| 08:39 | <zcorpan> | I would agree to standardize *if* 2+ browsers want to implement. |
| 08:40 | <othermaciej> | yeah, I think a conditional statement like that would be justified, but that's not what his bugs say. They make it sound like ~WHATWG has already decided, so get on board~ |
| 08:40 | <annevk> | othermaciej: thanks, that all sounds reasonable |
| 08:41 | <annevk> | othermaciej: in the Bugzilla issue I asked for evidence that the request is widespread, we'll see I suppose |
| 08:41 | <annevk> | But I tend to agree that syncing with a hidden input is easy enough |
| 10:40 | <jochen__> | how'd I go about getting https://github.com/w3c/wpt-tools/pull/164 merged? |
| 10:44 | <annevk> | jochen__: prolly talk to jgraham |
| 10:49 | <Ms2ger> | Look at the history for that runner and find someone who uses it? |
| 10:53 | <mkwst_> | MikeSmith has the most commits/reviews. But they're mostly from 2014. *cough* :) |
| 11:05 | <jgraham> | jochen__: Merged, but really if your workflow involves the runner you should find a better workflow :) |
| 11:36 | <zcorpan> | annevk: thanks for fixing snapshots for quirks mode |
| 11:37 | <annevk> | Does anyone know if there is a file system where the directory name can be empty? |
| 11:39 | <jgraham> | annevk: Sounds implausible |
| 13:28 | <jochen__> | annevk: mind looking at the document.open PRs again (html/wpt)? |
| 13:56 | <annevk> | jochen__: are we closer to figuring out what the security model should be? |
| 13:56 | <annevk> | I'll have a look in a bit |
| 14:22 | <annevk> | zcorpan: so there are a lot of people asking about readonly-like semantics and the top answer is a bunch of JavaScript |
| 14:22 | <annevk> | zcorpan: top answer having like >300 votes, so maybe it's something worth considering |
| 14:22 | <zcorpan> | annevk: got a link? |
| 14:23 | <annevk> | http://stackoverflow.com/questions/368813/html-form-readonly-select-tag-input |
| 14:23 | <annevk> | http://stackoverflow.com/questions/37762671/how-to-create-readonly-select-box-but-i-will-post-that-value |
| 14:23 | <annevk> | http://stackoverflow.com/questions/155291/can-html-checkboxes-be-set-to-readonly |
| 14:23 | <annevk> | http://stackoverflow.com/questions/4727974/how-to-post-submit-an-input-checkbox-that-is-disabled |
| 14:23 | <annevk> | They're from OP in the Firefox bug |
| 15:39 | <jochen__> | annevk: basically we all agree that we disagree with the one that is in the spec :) |
| 15:40 | <annevk> | jochen__: if you can guarantee an issue will be filed once you and bz are ready I'll go ahead and merge all the things |
| 15:41 | <jochen__> | let's file one immediately |
| 15:41 | <annevk> | I guess I'll remember it too since I don't like security mismatches |
| 15:41 | <annevk> | Thanks, I'll go merging things then |
| 15:43 | <jochen__> | https://github.com/whatwg/html/issues/2360 |
| 15:45 | <jochen__> | what's the bar for being allowed to merge stuff to wpt btw? |
| 15:45 | <jochen__> | or in other words, can I haz access plz? |
| 15:47 | <Ms2ger> | Being trusted to review sufficiently well :) |
| 15:47 | <Ms2ger> | Have you done reviews? |
| 15:51 | <jochen__> | i reviewed the referrer policy stuff |
| 15:51 | <jochen__> | (/referrer-policy/) |
| 15:52 | <jochen__> | but happy to just review stuff for a bit more and come back later |
| 16:09 | <wanderview> | annevk: was there some question about ancestorOrigins sticking around? |
| 16:09 | <annevk> | wanderview: there's a question of how it should work |
| 16:10 | <annevk> | wanderview: https://github.com/whatwg/html/issues/1918 |
| 16:11 | <wanderview> | annevk: I guess this blocks Client.ancestorOrigins as well then |
| 16:11 | <wanderview> | in service worker pec |
| 16:11 | <wanderview> | spec |
| 16:11 | <annevk> | wanderview: for us it does, yes |
| 16:11 | <annevk> | wanderview: it would be bad to undermine bz |
| 16:14 | <annevk> | Domenic: the numbers in https://github.com/w3c/web-platform-tests/issues/3018 seem quite good |
| 16:14 | <annevk> | Domenic: tweet? |
| 16:14 | <Domenic> | annevk: yeah :) |
| 16:18 | <annevk> | Domenic: I think I found a bug just browsing that coverage report |
| 16:19 | <Domenic> | Oh neat! In the file stuff I'd guess? The fact there were several uncovered branches there looked suspicious |
| 16:19 | <annevk> | Domenic: https://url.spec.whatwg.org/#file-host-state shouldn't have to check for "includes credentials" as that's not possible for file URLs |
| 16:19 | <annevk> | Domenic: yeah, that also looked very suspect, guess I'll dive into this tomorrow |
| 16:20 | <annevk> | Domenic: tooling is amazing |
| 16:23 | <wanderview> | annevk: JakeA: how important is it to provide Client.ancestorOrigins if we remove Client.frameType? |
| 16:23 | <wanderview> | do I have to implement .ancestorOrigins when .frameType is removed to avoid breaking a critical use case? |
| 16:26 | <Domenic> | MikeSmith: botie is gone again |
| 16:48 | <JakeA> | wanderview: it isn't something I've heard a lot of requests for |
| 16:50 | <wanderview> | JakeA: I guess there is this: https://github.com/w3c/ServiceWorker/issues/1007 |
| 17:17 | <zcorpan> | Domenic: can you have another look at the new changes in https://github.com/whatwg/html/pull/2355 (and the test)? |
| 17:31 | <tobie> | annevk: do all of the whatwg specs have auto pr branch deploys? |
| 17:32 | <annevk> | tobie: pretty much |
| 17:33 | <MikeSmith> | Domenic: botie is basic |
| 17:42 | <tobie> | annevk: my code is assuming that is the case. So we need to somehow special case it that's not so. |
| 17:53 | <annevk> | tobie: I don't understand, we simply only make it work for specs that have that setup |
| 17:54 | <annevk> | tobie: in the end all specs should have that setup, those that don't are buggy |
| 17:54 | <tobie> | annevk: wfm |
| 18:01 | <tobie> | annevk: OK so you be able to go ahead and add repos now |
| 18:01 | <tobie> | annevk: if you ping me with the repo name, I can run a script to update all open PRs |
| 18:02 | <tobie> | annevk: it's too complicated to automate this for now, due to a GH API issue. |
| 18:04 | <annevk> | Domenic: so if you're not tweeting I can |
| 18:05 | <annevk> | tobie: let's do it tomorrow, okay? |
| 18:05 | <tobie> | annevk: sure |
| 18:05 | <tobie> | annevk: ping me |
| 18:05 | <annevk> | will do |
| 18:05 | <tobie> | annevk: (might be out of office tomorrow. we'll see) |
| 18:07 | <annevk> | tobie: Friday or next Monday is fine too, will ping and we'll see |
| 18:08 | <Domenic> | annevk: oh, sure, I thought that was the plan |
| 18:15 | <annevk> | Domenic: done |
| 18:28 | <smaug> | no zcorpan |
| 18:28 | <smaug> | hmm, perhaps foolip knows |
| 18:28 | <smaug> | about MouseEvent.offsetX/Y |
| 18:29 | <smaug> | webkit based engines seem to cache the value after first getter call |
| 18:29 | <smaug> | yet the spec doesn't hint anything like that |
| 20:26 | <wanderview> | annevk: if I want to make a PR to service worker spec... is there a build step I need to run? |
| 20:27 | <annevk> | wanderview: not per se, but if you have bikeshed you could run that |
| 20:27 | <wanderview> | annevk: I modify the .bs file and then run bikeshed? |
| 20:28 | <annevk> | wanderview: not really sure what their policies are though |
| 20:28 | <annevk> | wanderview: yeah |
| 20:28 | <annevk> | wanderview: if they don't have PR instructions that is worthy of an issue |
| 20:44 | <wanderview> | annevk: I guess the CONTRIBUTING.md file does mention it in there |
| 20:58 | <wanderview> | JakeA: did you forget to re-generate the index.html after you removed the skip-service-worker flag? when I run bikeshed on the pristine checkout of the repo it seems to make those changes... |
| 20:59 | <JakeA> | Hmm, will check |
| 21:19 | <wanderview> | JakeA: I guess I get this: LINK ERROR: No 'dfn' refs found for 'skip-service-worker flag'. |
| 21:19 | <wanderview> | maybe just the fetch side of the change landed? |
| 21:46 | wanderview | made his first pull request against the ServiceWorker spec. |
| 23:08 | <MikeSmith> | wanderview: nice PR |
| 23:49 | <foolip> | smaug: is this caching that can be observed? |
| 23:51 | <foolip> | smaug: at a glance it looks like it depends on things that can't be changed with any init*Event(), but maybe I'm missing something :) |
| 23:51 | <smaug> | foolip: caching can be observed |
| 23:52 | <smaug> | foolip: https://bugzilla.mozilla.org/show_bug.cgi?id=1339758#c11 |
| 23:53 | <foolip> | smaug: oh, so if the layout is invalidated by the event handler, the event's offsetX/Y isn't? |
| 23:54 | <smaug> | right, in Webkit and Blink at least |
| 23:54 | <smaug> | and Edge too, but it has apparently different behavior |
| 23:54 | <smaug> | my interpretation is that Gecko works per spec, but bz thinks Edge might |
| 23:55 | <smaug> | but webkit/blink are certainly wrong |
| 23:55 | <foolip> | smaug: did offsetX go and disappear spec side? It used to be in https://w3c.github.io/uievents/#interface-MouseEvent I think |
| 23:55 | <smaug> | foolip: it is not there |
| 23:55 | <smaug> | in CSS OM |
| 23:56 | <foolip> | https://drafts.csswg.org/cssom-view/#extensions-to-the-mouseevent-interface it is |
| 23:57 | <smaug> | so, do you happen to know the reason for caching? Sounds like no :) And I think we should figure out what actually should happen here |
| 23:58 | <smaug> | specing webkit/blink behavior would be sad, since the caching happens rather random time |
| 23:58 | <foolip> | smaug: no, this is the first time I've seen it, but presumably because of perf at some point. I would ask dtapuska to investigate and explain |
| 23:58 | <smaug> | (whoever happens to access the getter first time) |
| 23:59 | <foolip> | what is https://drafts.csswg.org/cssom-view/#dom-mouseevent-offsetx trying to say though? "position where the event occurred" in past tense? |