| 02:27 | <MikeSmith> | about github webhoooks, does anybody here know if there is some way to get github to retry a webhook it if times out or fails? |
| 02:37 | <karlcow> | MikeSmith: I don't think it's possible. (I assume you meant when the POST from gitHub to your server has failed, because your server had a broken leg) |
| 02:39 | <karlcow> | payloads have also a max size of 5 MB. Above that the webhook will not happen. |
| 02:39 | <karlcow> | https://developer.github.com/webhooks/ |
| 02:42 | <karlcow> | Oh let me fix one thing |
| 02:43 | <karlcow> | There is a manual retrigger |
| 02:43 | <MikeSmith> | karlcow: thanks |
| 02:43 | <MikeSmith> | yeah I can manually re-run it from the github UI |
| 02:43 | <karlcow> | https://github.com/[owner_name]/[repo_name]/settings/hooks/unique_id |
| 02:44 | <karlcow> | under Recent Deliveries |
| 02:44 | <MikeSmith> | yeah |
| 02:44 | <MikeSmith> | that is what I use |
| 02:44 | <MikeSmith> | every day |
| 02:44 | <karlcow> | ouch |
| 02:44 | <MikeSmith> | for https://github.com/w3c/web-platform-tests/ |
| 02:44 | <MikeSmith> | yeah the thing is, for web-platform-tests it generates a *ton* of webhook requests every day |
| 02:45 | <MikeSmith> | dozens every day |
| 02:45 | <karlcow> | You are listening to "*" or specific events. |
| 02:45 | <MikeSmith> | well one thing is, github unfortunately does not give much granularity on what you can listen for |
| 02:46 | <karlcow> | on github.com/webcompat/web-bugs. We probably only generate 100 issues event a day. |
| 02:46 | <MikeSmith> | yeah most of the events are useless and you never want to do anything for them |
| 02:47 | <MikeSmith> | but for pull requests the important ones are “opened” and “closed” and “syncronized” |
| 02:47 | <karlcow> | For us it helps us to do labelling automagically depending on a couple of criteria |
| 02:47 | <MikeSmith> | right |
| 02:47 | <MikeSmith> | but we are using it to mirror the PR branches |
| 02:47 | <MikeSmith> | so for that all we care about is opened/closed/syncronized |
| 02:48 | <karlcow> | gotcha |
| 02:48 | <MikeSmith> | and not things like “edited” or “review requested” etc etc |
| 02:48 | <MikeSmith> | so if those fail I don’t care |
| 02:48 | <MikeSmith> | but if an opened/closed/syncronized fails I care a lot |
| 02:49 | <MikeSmith> | so what I do is, I have some bookmarklets I wrote to filter out all the noise from the Recent Deliveries logs |
| 02:49 | <MikeSmith> | so I can find just the opened/closed/syncronized fails |
| 02:49 | <karlcow> | :( |
| 02:49 | <MikeSmith> | yeah :( |
| 02:50 | <MikeSmith> | I have to just manually click the Redeliver button for those |
| 02:50 | <karlcow> | Maybe a good bug report for GitHub on having a URI with a list of all recent fails with a JSON format and a way to retrigger those. |
| 02:50 | <MikeSmith> | so... would much rather that Github just retried them some number of times if they fail |
| 02:50 | <MikeSmith> | yeah |
| 02:52 | <MikeSmith> | anyway it’s not a huge hardship |
| 02:52 | <MikeSmith> | just annoying |
| 02:53 | <karlcow> | add another point of failure by automating with webdriver api and selenium :) |
| 02:55 | <MikeSmith> | haha |
| 02:56 | <MikeSmith> | yeah but since I don’t know how to automate with webdriver I would ask somebody else to set it up and so they after that they would be responsible for dealing with the failures instead of me |
| 02:56 | <MikeSmith> | in other words, great plan |
| 02:57 | <MikeSmith> | good brainstorming! |
| 02:58 | <karlcow> | ;) |
| 06:37 | <annevk> | mathiasbynens: 🍰🎉 |
| 07:21 | <annevk> | hsivonen: does XUL require external DTDs? |
| 07:25 | <hsivonen> | annevk: yes :-( |
| 07:25 | <hsivonen> | annevk: that's the whole point. the DTD varies by localization, so the DTDs come from the language pack |
| 07:26 | <annevk> | hsivonen: I'm on board with parsing the internal subset, I don't know how much the external subset varies from that, it might be that an implementation could reuse quite a bit of code and we'd just never expose it to the web |
| 07:27 | <annevk> | hsivonen: but it sounds like there's not a real interest in addressing that issue |
| 07:27 | <annevk> | hsivonen: addressing XML5, I mean |
| 07:32 | <hsivonen> | annevk: it seems like this isn't the time for XML5. I can sympathize with not wishing to take on the scope creep of switching to XML5 if the goal is just to get memory-safety for XML 1.0 4th ed. |
| 07:34 | <TabAtkins> | WebIDL style opinion: I have a set of subclasses that all share an attribute. *One* of them wants to treat the attribute as readonly; the rest treat it as mutable. Should I do the technically-correct thing, and mark it as "readonly attribute" on the superclass, then "inherit attribute" on all but one of the subclasses; or do the easy thing and just put |
| 07:34 | <TabAtkins> | "attribute" on the superclass, then describe in prose that the one subclass ignores writes? |
| 07:34 | <annevk> | hsivonen: yeah, makes sense |
| 07:34 | <annevk> | hsivonen: given https://bugzilla.mozilla.org/show_bug.cgi?id=501837 I think we should consider XML 1.0 5th though |
| 07:34 | <annevk> | hsivonen: but meh |
| 07:35 | <annevk> | hsivonen: did you ever discuss with the JavaScript folks changing the JavaScript String type to be UTF-8 or UCS-2? |
| 07:35 | <annevk> | hsivonen: I mean, supporting a UTF-8 string type |
| 07:37 | <annevk> | hsivonen: I tried to convince Waldo he should give it a shot or at least strongly consider it, but not much luck thus far |
| 08:21 | <hsivonen> | annevk: changing JS string internals to UTF-8 was discussed at one point |
| 08:21 | <hsivonen> | annevk: quite a while ago |
| 08:21 | <hsivonen> | annevk: but in good news, script parsing directly from UTF-8 seems to be going ahead |
| 08:22 | <annevk> | hsivonen: so I don't really mean breaking the API contract with the web, just to have an additional internal string type (or replace the ASCII-only one) |
| 08:22 | <hsivonen> | annevk: it's not ASCII-only, it's Latin-1 |
| 08:22 | <hsivonen> | but yeah |
| 08:22 | <annevk> | ok |
| 08:22 | <hsivonen> | I didn't mean breaking the Web-visible API, either |
| 08:23 | <annevk> | Ah, parsing from UTF-8 sounds nice, hopefully we don't have the V8 bottleneck then if you hit an emoji in a comment |
| 08:23 | <yoav> | annevk: Thanks for reviewing https://github.com/whatwg/fetch/pull/547 Test-wise, I think the best way to go is to use potential destination as part of https://github.com/whatwg/html/pull/2588 and then land it alongside a Chrome CL with the right tests |
| 08:23 | <hsivonen> | annevk: see also https://bugzilla.mozilla.org/show_bug.cgi?id=1355106 |
| 08:24 | <hsivonen> | annevk: I've been trying to promote not repeating that V8 design |
| 08:24 | <annevk> | yoav: that's reasonable, I forgot this requires changes to the HTML Standard, that should ensure the relevant bugs get filed at least |
| 08:24 | <annevk> | hsivonen: great, I wasn't aware you were on top of all that |
| 08:24 | <hsivonen> | annevk: AFAICT, we aren't headed towards that V8 design |
| 08:26 | <yoav> | Domenic: would you be interested in adding the "potential destination" bits to your PR? Or would you like me to do it? |
| 08:28 | <nox> | annevk: "we don't have the V8 bottleneck then if you hit an emoji in a comment" |
| 08:29 | <nox> | What a time to be alive! |
| 08:38 | <gsnedders> | do I want to ask what the V8 bottleneck is? does it convert everything to utf-16 codeunits when it hits a non-ASCII/latin1 byte? |
| 08:39 | <annevk> | Emojis are so great at making people that otherwise wouldn't care put up the right i18n infrastructure |
| 08:40 | <annevk> | gsnedders: I think that's basically it, though I don't think it has to redo everything |
| 08:40 | <annevk> | gsnedders: but it's a Unicode performance cliff effectively |
| 09:12 | <mounir> | tobie: _requiring_ a user activation for permission prompt might be a bit agressive but I know there are some experiment in this direction in Chrome |
| 09:12 | <mounir> | tobie: if other browsers are okay with this, it might work |
| 09:38 | <yoav> | annevk/Domenic: Related tests and Chrome CL at https://codereview.chromium.org/2903653005 |
| 09:39 | <yoav> | I need to writeup an Intent to ship for this, as this modifies shipped behavior |
| 09:40 | <yoav> | It'll also require some HTTPArchive digging to see that there aren't many sites already using the "onerror" fallback |
| 09:40 | <annevk> | yoav: yay |
| 09:41 | <annevk> | yoav: I suspect you know but Domenic isn't usually around until quite a bit later |
| 09:41 | <yoav> | yeah, I'm assuming he'll catch up later, as he's logged in |
| 10:09 | <nox> | Is drafts.fxtf.org down? |
| 10:09 | <annevk> | nox: loads here |
| 10:10 | <nox> | Ah it works again here. |
| 10:14 | <tobie> | mounir: thanks feel free to comment on the PR (https://github.com/w3c/sensors/pull/207), the issue (https://github.com/w3c/sensors/issues/196) and loop the relevant people in, if necessary. |
| 11:47 | <annevk> | Is it a problem that request headers such as * and _ end up as HTTP__ in CGI and that if you use both you get only a single HTTP__ for the last header transmitted? |
| 11:47 | <annevk> | Seems there's at least some information loss |
| 13:23 | <Domenic> | I mean, I am not super surprised about CGI being a lossy translation of HTTP semantics |
| 13:26 | <gsnedders> | does CGI not pass everything through as envrionment variables? |
| 13:26 | <gsnedders> | any hence is limited by what's a valid env? |
| 13:26 | <jgraham> | Yes |
| 14:42 | <annevk> | So I looked around and there is a document describing CGI but it doesn't cover this case: https://tools.ietf.org/html/rfc3875#section-4.1.18 |
| 14:57 | <zcorpan> | I'm pretty much behind in github notifications. If something needs my attention, please @mention me or drop a link here |
| 15:14 | <Domenic> | zcorpan: there's a parser open issue, besides the mega PR... https://github.com/whatwg/html/issues/2704 |
| 15:24 | <zcorpan> | Domenic: thanks |
| 15:26 | <annevk> | hsivonen: I tried to do some more digging on the namespaces front, https://lists.w3.org/Archives/Member/w3c-xml-wg/1997Aug/0088.html seems to suggest RDF was important enough to consider a special case for, without necessarily solving it generically |
| 15:30 | <jugglinmike> | annevk: We'll see if anyone thinks this is important.. https://github.com/httpwg/http11bis/issues/26 |
| 15:33 | <annevk> | jugglinmike++ |
| 15:33 | <jugglinmike> | :) |
| 15:50 | <hsivonen> | annevk: https://archive.mozilla.org/pub/firefox/try-builds/hsivonen⊙mc/ has builds for Windows and Mac in case you are interested in trying a browser with Encoding Standard-compliant converters |
| 15:51 | <hsivonen> | (not 100% compliant integration, though. some old BOM and EOF handling bugs remain and need follow-ups to fix) |
| 15:53 | <hsivonen> | annevk: in any case, RDF has had the most committed to the "identifiers are URIs" meme and has been since before XMLNS and RDF/XML were final |
| 15:56 | <zcorpan> | MikeSmith: hsivonen: https://github.com/validator/validator/blob/3530d33b339a64fb3dd76673257d1fb7b930b9ea/schema/svg11/svg-datatypes.rnc#L73 is sadness (and means <circle r=5/> doesn't get an error for the attribute value) |
| 15:57 | <hsivonen> | zcorpan: indeed, those datatypes could use a custom library |
| 17:50 | <Mek> | random thought: should the processing model section in the html spec somehow normatively suggest that user agents should not starve particular task queues? (case in hand, chrome currently has arguably a bug where posting messages to a messageport in the right way can cause chrome to starve all other task queues, which arguably is perfectly fine according to the spec...) |
| 18:13 | <ben_thatmustbeme> | had a question come up in microformats parsing, what is the textContent of a self-closing tag |
| 18:14 | <ben_thatmustbeme> | https://dom.spec.whatwg.org/#dom-node-textcontent says for Elements textCotent must be The concatenation of data of all the Text node descendants of the context object, in tree order. |
| 18:14 | <ben_thatmustbeme> | but is it Null or "" if there are no text node descendants |
| 18:28 | <ben_thatmustbeme> | full breakdown of what i am hitting is here https://github.com/indieweb/microformats-ruby/issues/72 |
| 18:29 | <Domenic> | ben_thatmustbeme: empty string |
| 18:30 | <ben_thatmustbeme> | thanks |
| 18:32 | <ben_thatmustbeme> | is there anywhere that is clear about that? |
| 18:32 | <ben_thatmustbeme> | i feel like that should be more clear, just don't know if i'm missing something |
| 18:33 | <Domenic> | ben_thatmustbeme: in general it's understood that the concatenation of an empty set of strings is the empty string; I guess we could eventually define that explicitly, but it's generally true in programming. |
| 18:38 | <ben_thatmustbeme> | guess i never thought about it. both ruby and php agree on that |
| 19:27 | <annevk> | Mek: I'm not sure what you mean by starve |
| 19:27 | <annevk> | Mek: maybe file a bug since I won't be able to follow-up properly for a while |
| 19:29 | <Mek> | annevk: starve is the language the example used (" The user agent could then give [...] events preference over other tasks [...], keeping the interface responsive but not starving other task queues,"), but basically make sure that all task queues will eventually make progress |
| 19:32 | <annevk> | Mek: as long as there are tasks on one task source, not handling the others is acceptable, but yeah, maybe it should not be, but not sure what you could require there meaningfully |
| 19:33 | <annevk> | Mek: not all user agents implement the same task sources either |
| 19:33 | <annevk> | Mek: and a lot of UI events seem to move from task sources to the "animation frame moment" |
| 19:34 | <annevk> | Mek: so nothing there really seems stable enough to me to clean up and figure out an ideal model |
| 19:34 | <Mek> | yeah, it definitely doesn't seem like something that can have strong requirements |
| 19:35 | <Mek> | it just "feels" wrong that posting the "right" messages from an onmessage event can cause chrome to never get to any other tasks... but maybe that's just a quality-of-implementation thing |
| 20:44 | <jugglinmike> | JakeA annevk as far as I can tell, service workers should intercept synchronous XHR requests in the same way they intercept asynchronous XHR requests. Is that correct? |
| 20:51 | <JakeA> | jugglinmike: yes, but we don't in Chrome right now. It created a sort of deadlock. |
| 20:55 | <jugglinmike> | JakeA: I'll have to research a bit more. Chromium has a test for this, but I don't think it's correct |
| 20:56 | <wanderview> | not sure we have tested it, but i think sync xhr interception should work in FF |
| 20:56 | <wanderview> | our sync xhr spins the event loop, so I don't think we will deadlock... but who knows |
| 20:56 | <annevk> | That's a bug in Fx though |
| 20:57 | <wanderview> | annevk: why? we're not running javascript on the main thread here |
| 20:57 | <annevk> | But would be fun to test interaction with postMessage() and friends and such |
| 20:57 | <annevk> | wanderview: UI event handlers run iirc |
| 20:57 | <jugglinmike> | Here's the test |
| 20:57 | <jugglinmike> | https://chromium.googlesource.com/chromium/src.git/+/master/third_party/WebKit/LayoutTests/http/tests/serviceworker/sync-xhr-doesnt-deadlock.html |
| 20:58 | <jugglinmike> | and https://chromium.googlesource.com/chromium/src.git/+/master/third_party/WebKit/LayoutTests/http/tests/serviceworker/resources/sync-xhr-doesnt-deadlock-iframe.html |
| 20:58 | <jugglinmike> | and https://chromium.googlesource.com/chromium/src.git/+/master/third_party/WebKit/LayoutTests/http/tests/serviceworker/resources/sync-xhr-doesnt-deadlock.js |
| 20:58 | <jugglinmike> | and finally https://chromium.googlesource.com/chromium/src.git/+/master/third_party/WebKit/LayoutTests/http/tests/serviceworker/resources/sync-xhr-doesnt-deadlock.data |
| 20:59 | <jugglinmike> | Currently, Chrome passes this test because the Service Worker doesn't intercept the request, and the `.data` file is retrieved from the server directly |
| 20:59 | <jugglinmike> | but I'm migrating this test to WPT, and Firefox fails it |
| 21:00 | <jugglinmike> | because in Firefox, the worker correctly intercepts the request and response with the result of fetching "404resource" |
| 21:01 | <jugglinmike> | So I'm removing the `.data` file, and having the worker respond to requests for it with a `new Response` |
| 21:01 | <jugglinmike> | that way, Chrome fails the test (because the worker doesn't intercept the request), and Firefox passes (because the work does intercept, and the frame does not deadlock) |
| 21:02 | <wanderview> | I guess that works |
| 21:02 | <wanderview> | I wouldn't lose much sleep if we just said sync XHR wasn't intercepted, thoguh |
| 21:03 | <jugglinmike> | Neither would I, but I can't submit a test like that without a spec change |
| 21:03 | <jugglinmike> | Now normally, when modifying a test like this, I would persist some alternate Chromium version in order to maintain test coverage |
| 21:04 | <jugglinmike> | but in this case, I don't think there is anything meaningful to maintain. As written, Chromium's version isn't really doing anything |