2018-08-01 [19:43:24.0000] Sigyn is useless... [19:44:46.0000] Domenic: you need to op it lol [19:45:40.0000] Pretty sure I did [19:48:21.0000] its just listed as a member when i check [19:48:43.0000] Yeah but it should be able to op itself like I do with ChanServ [19:49:07.0000] Well, I manually made it op, let's see what happens [19:49:30.0000] It would be pretty sad if we could have stopped this spam at any time but failed [20:23:29.0000] So Sigyn is half-useless [22:50:07.0000] jumping at the opportunity to employ an IRC ad service that spams a message to the same channel 20 times [22:50:14.0000] that is an indication of a quality spammer [05:46:36.0000] So is there some solution for this channel being 100% spam over the last 12 hours? [05:48:45.0000] Or has everyone given up on it anyway? [05:58:14.0000] jgraham: not given up but some mitigation has been attempted using https://github.com/freenode/Sigyn but clearly it’s not worked very well [05:59:09.0000] and the messages aren’t really spam; they’re instead some kind of trolling attack against the freenode admins [06:01:02.0000] ...and maybe sent using some kind botnet such that it can’t be prevented through simple IP-range blocking or whatever [06:12:21.0000] another channel I'm in dealt with it by blocking anyone from talking unless the person is on a "voiced" list [06:18:43.0000] MikeSmith: I kind of meant the channel in general rather than the spam in particular; historically it's fairly unusual for things to be this quiet for this long [06:18:51.0000] MikeSmith: But thanks for the update [06:50:02.0000] I suspect vacation/backlog as reasons for quietness, but have not seen stats [06:52:15.0000] Could be. I started to wonder if everyone had moved to some backchannel on slack or something [06:58:14.0000] I’m not aware of any, FWIW [06:58:42.0000] Maybe everyone just ran out of things to say :) [07:16:54.0000] maybe everyone is saving their best material for tpac [08:29:49.0000] annevk: https://github.com/whatwg/html/pull/3811 LGTY? [08:40:32.0000] Ms2ger: Thanks for setting +r. [08:41:17.0000] Np [08:51:36.0000] Domenic: reviewed [08:52:46.0000] Domenic: it's gonna take at least another week before I worked through my backlog; rather busy summer [08:52:55.0000] have worked* [08:55:22.0000] annevk: sure no problem. Feel free to use "LGTM with nits" approval to reduce round trips :) [09:03:56.0000] Domenic: If a window's referrer policy was set to "no-referrer", would top-level module worker requests from this window use that policy, and thus omit a referrer, or use a default policy, and send the window's URL? [09:04:39.0000] https://github.com/web-platform-tests/wpt/blob/master/workers/modules/dedicated-worker-import-referrer.html#L93 has me a little bit confused as I compare it with the spec, but I definitely could be reading something wrong [09:07:00.0000] Spec seems to eventually defer to “outside settings” referrer, but I think that conflicts with the test case. [09:08:07.0000] s/referrer/referrer policy, in my latest msg [09:31:17.0000] domfarolino: hmm yeah those tests seem wrong [09:31:24.0000] The ones *inside* should use default referrer policy I think [09:31:29.0000] Although fixing that would be nice [09:31:42.0000] That's a larger problem space: https://github.com/w3c/webappsec-referrer-policy/issues/111 [09:57:13.0000] Domenic: and those *inner* requests that use the default referrer policy, will eventually resolve to using that of fetch client settings object, (which’ll be “no-referrer” in my example) right? [09:57:37.0000] Hmm... [09:57:53.0000] Also what you propose in that issue seems reasonable. [09:58:09.0000] Yeah just a decent amount of work [09:58:32.0000] I guess you're right they would resolve to "no-referrer" [09:58:35.0000] The reason I’m wondering if it’ll end up being “no-referrer” in that example is because we still use fetch client settings (outer setitjnfs) as the inner request’s client I think, right? [09:58:36.0000] So the tests further down are probably wrong too? [09:58:39.0000] Ah ok [09:58:41.0000] Yeah I think so [09:58:56.0000] Worth checking with the test author (probably nhiroki) to make sure I'm not missing anything [09:59:41.0000] Will do. He’s reviewing some refactoring I’m doing in that area so will run by him. [10:04:31.0000] I originally though we used “inner settings” as inner request clients but that does not seem to be the case. [12:44:33.0000] So now Token Binding is mostly gone again… [13:26:43.0000] https://fetch.spec.whatwg.org/#concept-construct-readablestream creates a non-byte ReadableStream, even though Fetch only enqueues Uint8Arrays. Is that optimizable internally, or should it change? [13:28:20.0000] Both, I think :). [14:32:17.0000] Domenic: This might be https://github.com/whatwg/fetch/issues/267. 2018-08-02 [23:17:30.0000] Domenic: interested in the `queueMicrotask` -- what is the expected purpose/usecase for this kind of scheduling? [23:20:37.0000] ondras: https://github.com/w3ctag/design-reviews/issues/294#issuecomment-408258727 might help [23:22:31.0000] annevk: well that mostly explains why the new api is better than resolve.then [23:22:39.0000] annevk: but I somewhat fail to see the use case for both [04:33:07.0000] ondras: https://github.com/whatwg/html/pull/3873 might also help [04:33:20.0000] (again, might 😊) [04:35:40.0000] annevk: thanks! this probably has all I need to educate myself :) [04:37:55.0000] in particular, the second example is something I can relate to. the first one looks pretty weird to me, but whatevs. [05:47:05.0000] Hey, has there been talk of a setTimeout variant that returns promises? I'm asking for a JavaScript API and I'd just prefer to implement something with a spec than something without. [05:47:18.0000] (Also, a setInterval that returns async iterators) [05:47:49.0000] benjamingr_: just talk afaik [05:48:06.0000] benjamingr_: don't think there's even an issue for it [05:48:28.0000] Can/should I open one? [05:48:59.0000] benjamingr_: sure, against whatwg/html [05:49:02.0000] `new Promise(r => setTimeout(r, 5000))` is a bit annoying, but pretty short already [05:49:18.0000] that's also true [05:49:44.0000] wanderview: one possible con for it is that there is already a way to do it and it wouldn't add a capability, on the other hand you'd be surprised at how wrong people get that simple one liner [05:50:04.0000] what would be interesting is if a "modern" timeout API could not only include promise support, but also maybe remove legacy clamping behavior [05:50:31.0000] but adding more stuff also makes any proposal more likely to fail [05:50:38.0000] maybe I should just drink my coffee [05:51:25.0000] lol, yeah, I don't think that's something we'll be able to do [05:51:51.0000] no? [05:53:06.0000] By the way and on a completley unrelated note: is there any eta for streaming fetch in firefox wanderview? I saw there is some interesting work involving it and wanted to offer to be a guinea pig since we are pretty heavy consumers of it on chrome. (And by all means do feel free to tell me that the current ETA is 'sometime' and it's not a priority) [05:53:45.0000] Re: timeout without clamping - we've discussed it a bunch in Node - I don't think there was enough interest but maybe I'm remembering it wrong. [05:53:46.0000] benjamingr_: there's dom.streams.enabled but I'm not sure if that covers fetch() [05:53:47.0000] benjamingr_: there are prefs you can enable to test today (and for like the last year) [05:54:10.0000] there's also javascript.options.streams, hmmm [05:54:35.0000] benjamingr_: a thorny cross global issue has kept it from shipping, but in theory thats finally being reviewed now'ish [05:54:40.0000] That does cover `fetch` yeah, I've been testing that - I'm sort of the person in my company who cares about firefox users' UX [05:54:48.0000] annevk: yea, you need both those prefs [05:55:30.0000] benjamingr_: <3 [05:55:32.0000] Yeah, it works for us with those perfs - works pretty well too. Firefox WebRTC has more (and better) connections than Chrome at the moment but it's losing in UX on our infrastructure without streaming fetch and wins with it - it's more of an office bet than anything. [05:57:06.0000] benjamingr_: posting your expected wins in the stream bug may help folks prioritize it [05:57:24.0000] or maybe annevk can just relay the information [05:58:05.0000] Seeing it from someone developing an actual product seems potentially useful [05:59:30.0000] Well, we're building a p2p streaming platform on top of WebRTC and hls/mpeg-dash - streaming fetch means we can share segments before we finished downloading them which really improves UX on congested networks - especially in places like southeast Asia and Latin America. We see streaming fetch making the biggest difference there. [05:59:49.0000] benjamingr_: this is the bug if you want to chime in with some actual data, etc: https://bugzilla.mozilla.org/show_bug.cgi?id=1389628 [06:01:17.0000] Thanks, I saw that - I'm usually afraid I'll just be annoying in these bugs - I dislike it when people show up and "demand" work on something myself so I usually try not to do it myself. I only bugged you about it now since I saw recent activity and we were already talking. [06:02:19.0000] I understand, but I would look at it more as sharing real world data the browser vendor is probably lacking... [06:05:26.0000] https://github.com/whatwg/html/issues/3875 hope this is appropriate, feel free to tell me to edit/fix it in some way [07:48:26.0000] Ugh: https://bugzilla.mozilla.org/show_bug.cgi?id=1477286 [07:48:45.0000] I thought we only had synthetic click events and were on track to remove synthetic submit events causing action? [12:53:34.0000] Oh no :( [16:07:34.0000] Domenic: yt? 2018-08-03 [17:06:25.0000] does anyone know of a list of non-spec compliant features in mobile safari? [17:06:34.0000] i'm particularly interested in XHR [17:40:09.0000] KiChjang, perhaps implementing Feature-Policy: sync-xhr ? [17:40:26.0000] and fetch? [17:40:34.0000] wait, is that CSP? [17:40:50.0000] that would affect fetch [17:41:06.0000] FP is newish [17:42:09.0000] WebAuthn API [17:42:40.0000] hmm... that doesn't seem to be something i'm interested in knowing [21:25:55.0000] TimothyGu: sorry, I won't get to event handlers this week [21:26:08.0000] TimothyGu: forgot about a public holiday [07:44:22.0000] annevk: No problem [16:14:32.0000] In https://fetch.spec.whatwg.org/#concept-main-fetch, I see "6. If the recursive flag is set, return response." IIUC, the recursive flag is set for any non-navigation redirect, so none of those will do things like set the response's url list. Is that right? [16:21:24.0000] where would the recursive flag be set? "fetch" (i.e. https://fetch.spec.whatwg.org/#concept-fetch) seems to always call main fetch witohut the flag set [16:22:13.0000] actually, that is what you said, never mind [16:23:13.0000] either way it seems like the outer main fetch would still eventually do all those further steps? [16:24:58.0000] Mek: Yeah, I think you're right. [16:25:04.0000] Thanks. 2018-08-04 [19:11:29.0000] Hm.. I'm trying to programmatically detect use of an accesskey="" trigger. [19:11:54.0000] Looking at monitorEvents() in Chrome, I found I get two interesting events that differ from other types of button/link triggers [19:12:06.0000] 1) A strange key value for the keydown event [19:12:28.0000] 2) A click event with e.details = 0, and a non-null inputCapabilities. [19:14:37.0000] But not sure if either of those is limited to accesskey triggers [19:15:22.0000] The strange keydown event is limited to chrome ( key: "∆"), not in Safari. so that one falls off. [19:15:42.0000] e.details = 0 seems cross-browser, but not sure if it's possible for other ways that can be zero for a non-regular click [19:16:52.0000] sorry, meant a null sourceCapabilities. Normally for click events sourceCapabilities is an input capabiltities object 2018-08-05 [14:10:51.0000] Found this digging through old tests https://simon.html5.org/specs/web-dom-core [14:11:30.0000] via https://lists.w3.org/Archives/Public/www-dom/2009JulSep/0026.html [14:11:41.0000] (last paragraph is fun) [14:38:05.0000] oh jeez RCS format diff [14:44:38.0000] 😱 2018-08-06 [19:12:32.0000] https://github.com/gsnedders/dom-test-suite has that old DOM testsuite in git, if anyone cares [19:12:39.0000] /me forgets why he did that now [21:58:11.0000] We are still running versions of that suite for jsdom... maybe not necessary anymore... although given that we still can't mark WPT test files as partially passing, we might not be able to use WPT to replace all that coverage just yet. [05:14:39.0000] Is https://w3c.github.io/DOM-Parsing/#the-domparser-interface the correct spec to read for DOMParser? [05:41:39.0000] hsivonen: yes [06:13:20.0000] annevk: thanks [06:14:06.0000] TIL: Chrome adds the parseerror element as the first child of root in the document returned by DOMParser instead of following the spec [09:00:31.0000] TabAtkins: Is there a good way for me to search Shepherd for uses of https://fetch.spec.whatwg.org/#concept-construct-readablestream? [09:00:44.0000] And if so, is it documented somewhere I should have looked? [09:02:26.0000] jyasskin: https://tabatkins.github.io/bikeshed/#cli-refs , but I don't have a way to search by URL. [09:03:52.0000] TabAtkins: I believe `bikeshed refs --text="construct a ReadableStream object"` searches for the definition, not the uses. [09:04:02.0000] Oh, I misread! [09:04:06.0000] :) [09:04:14.0000] No, don't have that functionality yet, but it's on my shortlist. [09:05:01.0000] I want to change the interface for that definition (https://github.com/whatwg/fetch/pull/781), but I'm worried I'll break uses outside Fetch. [09:05:14.0000] TabAtkins: Would you mind looking it up for me? [09:05:15.0000] yup, taht's precisely the use-case I want it for. [09:05:24.0000] I don't have the *data* yet, so no. [09:05:31.0000] Oh, ok. Thanks anyway. :) [09:05:34.0000] If I did, beleive me, the UI would be there immediately. [12:56:04.0000] So it appears document.open() can make the document's URL not equal to the URL of the corresponding session history entry. That's... fun. [12:56:12.0000] Can anyone think of other ways those things can get out of sync? [12:56:25.0000] smaug____: you may know ^ [13:27:00.0000] Tentatively TimothyGu and I believe this is very bad and should be fixed. A lot of the spec, and some impl code he dove through, assumes they are the same. [13:29:36.0000] Domenic: what is very bad? [13:30:54.0000] rniwa_: document.open() can make the document's URL not equal to the URL of its session history entry [13:31:06.0000] Domenic: oh, fascinating. [13:31:33.0000] Domenic: so history.push(~) and then document.open() can move the URL back to the original URL [13:31:44.0000] Domenic: but without adding a new history entry? [13:31:52.0000] Yeah also it breaks (per-spec) fragment navigation [13:31:58.0000] oh snap [15:02:58.0000] Domenic: can't recall. (I wouldn't be surprised if something in pushState handling could lead to similar behavior though) 2018-08-07 [02:34:37.0000] Is https://www.w3.org/2001/tag/doc/promises-guide/#resolve-promise the right link to resolve a promise in specese? [08:27:10.0000] Ms2ger: That's the one I use, assuming you created the promise with https://www.w3.org/2001/tag/doc/promises-guide/#a-new-promise. Note that we're playing fast and loose with both Realms and thread-safety there, but I think it's better to call that so we can fix it all up in one place than to try to DTRT yourself. [08:27:27.0000] Thx [08:41:14.0000] jyasskin said what I have been struggling to phrase since I saw this question earlier in the morning. [08:41:22.0000] :) [09:14:07.0000] annevk: hey, could you review my events pr :) [09:16:01.0000] let me know when you could get to it [09:16:05.0000] TimothyGu: I hope Thursday; I've had quite a bit of travel either due to vacation or moving later this month (as well as lots of paperwork) which has increased my backlog a lot and pushed everything back [09:16:40.0000] 😞 [09:16:43.0000] TimothyGu: I need a full day tomorrow for a meetup and after that I should have time again for full days of reviews [09:16:58.0000] Good luck then [09:17:29.0000] TimothyGu: yeah, I'm sorry, it isn't exactly how I thought things would work out either [09:21:02.0000] TimothyGu: Domenic doesn't feel comfortable reviewing it? [09:21:16.0000] annevk: I was hoping for a second opinion [09:21:37.0000] But we can merge and have you do a post-merge review [09:21:39.0000] It's pretty solid [09:21:49.0000] And no need to add to your workload [09:22:30.0000] I'll read through it quickly now then [09:28:00.0000] TimothyGu: Domenic: approved [09:28:08.0000] Thanks! [09:36:53.0000] https://github.com/whatwg/xhr/issues/217 is rather unclear to me still 😟 [13:32:59.0000] q+ [13:33:12.0000] q? [13:33:40.0000] q? [13:34:11.0000] oops wrong window 2018-08-08 [23:28:59.0000] I just get an error message "There were errors. Stopping." from html-build/build.sh. Is there a way to debug? [23:30:31.0000] falken: I can help now [23:30:49.0000] Great! [23:31:11.0000] I think that indicates a parse error [23:32:17.0000] falken: Any output difference when trying verbose? [23:32:24.0000] `-v`, that is [23:35:29.0000] domfarolino: DMed falken about it but apparently I/we may have recently regressed the error-reporting behavior [23:35:54.0000] in case of errors, the build should cat the .temp/wattsi-output file [23:36:14.0000] but it seems it might not be doing that in, at least in some cases [23:37:33.0000] ahh I see. That would be difficult to debug indeed. [23:37:37.0000] yup [23:58:11.0000] At the end of this year Web Forms 2.0 will have existed for 15 years... [23:59:25.0000] September 5 the first draft got shared in private [00:00:00.0000] Maybe we can try to get it implemented by then [00:00:36.0000] I initially wrote "Still has bugs" as subsequent sentence, but thought that'd be too negative [00:00:42.0000] Fortunately there's Ms2ger 😃 [00:01:00.0000] /me takes a bow [00:02:07.0000] heh [00:04:08.0000] I guess we probably now have some 20-year milestones of interest at https://www.w3.org/html/wg/wiki/History [00:04:49.0000] doctype sniffing, 1998-07 [00:59:29.0000] falken: I’ve not been able to reproduce the problem you ran into [00:59:41.0000] MikeSmith: hummm [01:00:18.0000] yeah I get the expected error report emitted to the console [01:01:08.0000] If it matters I'm not using local wattsi: "Local wattsi is not present; trying the build server..." [01:01:08.0000] but if you’re still able to reproduce it can file an issue with a test case, I can look [01:01:38.0000] oh [01:01:39.0000] I also often get "socket.error: [Errno 98] Address already in use" but even after killing the server the same error happened [01:01:50.0000] ah [01:02:23.0000] yeah the socket error happens if you ^C kill the build before it completes [01:02:49.0000] it’s because of the support for syntax-highlighting that I added recently [01:03:14.0000] that support relies on the build starting up a local web server [01:04:08.0000] if you have pkill or such installed, you can do `pkill python; ./build.sh` to kill that web server before you build again [01:04:46.0000] yea.. it didn't seem to matter if the socket error happened or not [01:04:47.0000] well, assuming you don’t have any other python process running (because that pkill invocation would kill them all) [01:04:51.0000] yeah [01:05:08.0000] yeah so I didn’t test the remote-wattsi case yet [01:05:12.0000] I will [01:55:18.0000] falken: so yeah thanks I can reproduce it with remote wattsi [02:23:36.0000] falken: https://github.com/whatwg/html-build/pull/181 has the fix [02:23:49.0000] thanks again for catching that [08:04:11.0000] MikeSmith: we should also use tricks to catch ^Cs and kill the server anyway [09:14:30.0000] Domenic: true [13:45:43.0000] hi, I noticed that Request.credentials is now (as of https://github.com/whatwg/fetch/commit/811575d6889026c68d55a327f79198dccfea403c in April) supposed to default to "same-origin" instead of "omit". This is not reflected in the living standard document for fetch: https://fetch.spec.whatwg.org/ [13:46:17.0000] The relevant line is https://github.com/whatwg/fetch/blob/master/review-drafts/2018-06.bs#L1057 -- what's the best way forward? Submitting an issue? Direct PR? [13:54:42.0000] rixx: why do you say it's not reflected in the living standard? (Also, why are you pointing to the review draft instead of the living standard?) [13:55:14.0000] rixx: the change in https://github.com/whatwg/fetch/commit/811575d6889026c68d55a327f79198dccfea403c appears in the living standard at https://fetch.spec.whatwg.org/#dom-request step 6.6. [13:58:55.0000] it does, but in the standard document it says 'Unless stated otherwise, it is "omit".', which sounds to me like it doesn't match that change [13:59:14.0000] But it is stated otherwise, on step 6.6. [14:03:09.0000] it does say that, thank you for pointing it out. I'd argue finding the valid value for credentials is a bit convoluted, then [14:03:21.0000] Thank you for clearing that up, sorry for the noise [14:04:24.0000] np! [15:51:47.0000] https://developer.mozilla.org/en-US/docs/Web/API/Request/credentials$compare?from=1403797&to=1403836 [15:52:22.0000] > even though the living standard document currently does not reflect it, same-origin is the default value as of.. 2018-08-09 [20:15:31.0000] https://lists.mozilla.org/pipermail/dev-platform/2018-August/022511.html is notable [20:15:46.0000] Firefox build dependency on Node [21:18:44.0000] oh hell no ... [22:04:46.0000] Hasimir: next I expect Vim will introduce a dependency on Node.. [22:05:20.0000] ..Vim already has dependencies on just about everything else there is [22:52:22.0000] that's just depressing, but at least I don't have to worry about my text editor [02:20:41.0000] MikeSmith: does the HTML Checker do URL validity? [02:36:50.0000] annevk: yes but not 100% conforming to the URL spec [02:36:59.0000] it just relies on galimatias [02:37:31.0000] ..which is no longer maintained and so is not up to date with the current URL spec [02:38:32.0000] kk [08:40:35.0000] annevk: btw I responded to your comments in https://github.com/whatwg/html/pull/3893… thanks for the review! [08:43:11.0000] TimothyGu: you’re right that there’s only one consumer, though Blink at least has two [08:43:58.0000] And yeah, I guess we should refactor that [08:45:02.0000] annevk: Hmm, has two of what? [08:46:17.0000] TimothyGu: remove all listener consumers [08:46:30.0000] ah [08:46:36.0000] TimothyGu: during doc teardown iirc [08:48:16.0000] annevk: just checking, LGTY with refactoring done? Any thoughts on style of refactoring, e.g. should we have a "remove all listeners and handlers" wrapper, or a "remove all handlers" utility, or...? [08:55:19.0000] Domenic: I don't think I'd block on refactoring [08:55:26.0000] /me looks [08:56:02.0000] For some reason GitHub is really slow [09:00:44.0000] Maybe my internet is just slow today [09:42:45.0000] annevk: do you prefer hreftranslate or hrefTranslate it wasn't clear in your comments [09:45:08.0000] dtapuska: oh sorry, I thought hreftranslate made sense given the precedent of hreflang, but on reflecting maybe overall consistency is better than this small local consistency [09:45:12.0000] reflection* [09:45:15.0000] Hm.. I always thought automatic-semi-colon insertion happens only if normal processing would produce an error. But it seems that it behaves differently for the return statement? In that return\n1+2 will always return undefined. [09:45:43.0000] I'm running into this as result if an odd minifier that tries to break code at the first opportunity after 1000 chars per line. [09:45:46.0000] result of an* [09:50:34.0000] annevk: ya policy is always is not to let one mistake propagate to others.. so I'd say go with hrefTranslate [09:52:51.0000] dtapuska: wfm [10:26:54.0000] Krinkle: https://tc39.github.io/ecma262/#prod-ReturnStatement [10:27:05.0000] return [no LineTerminator here] Expression `;` [10:31:40.0000] TimothyGu: Thanks. 2018-08-10 [02:53:10.0000] Travis cannot reach GitHub?! [02:53:25.0000] whatwg/xhr refuses to build because it cannot fetch .travis.yml [02:53:35.0000] https://travis-ci.org/whatwg/xhr/builds/414441341 [02:57:27.0000] It happens occasionally. [02:58:32.0000] I restarted it four times, but it seems it was succeeding in a different build... [02:58:39.0000] Not sure I fully understand what's going on [10:50:16.0000] Hmm definitely some build failures reaching GitHub for HTML too [10:50:37.0000] Interesting Travis also failed reaching prince.com. Maybe a Travis-side issue. 2018-08-11 [21:58:17.0000] annevk: What is the expected destination of a request coming from `event.respondWith(fetch(event.request))` in a ServiceWorker? [21:58:43.0000] annevk: Should it assume the destination of the input request, or be `""`, which seems to be the destination associated with `fetch()`s [22:00:51.0000] annevk: Given https://fetch.spec.whatwg.org/#dom-request > 13 doesn't copy over "destination" information, I imagine the destination will not be preserved, and thus will always represent fetch()? Or...? [23:10:07.0000] domfarolino: correct [23:10:20.0000] domfarolino: otherwise CSP could be misled [23:11:06.0000] domfarolino: though perhaps for that specific scenario it could be ok [23:12:14.0000] annevk: Yeah, I'm wondering if it would be helpful/non-breaking to copy over destination/initiator (context: https://github.com/whatwg/fetch/pull/785#issuecomment-412253141) [23:12:24.0000] (disclaimer: don't know much about CSP actually) [23:14:20.0000] It’s not okay I just remembered [23:15:11.0000] The service worker would have script access to the response, whereas the CSP policy might only expect it to render as image [23:19:00.0000] Oh interesting. Will take a closer look tomorrow, that seems problematic [00:30:46.0000] domfarolino: once priority is non-null it won’t be reset if you preserve it [00:31:05.0000] domfarolino: so I think your PR comment does not apply [04:16:54.0000] Hmm, Travis again had trouble reaching GitHub [04:47:03.0000] hayato: does blink have some optimization for mouseenter/leave which causes events to not be dispatched if ancestors don't have listeners? [04:47:16.0000] and is it possible that there is a bug when dealing with shadow DOM [04:47:31.0000] https://bugzilla.mozilla.org/show_bug.cgi?id=1478959 starts to smell like website relying on some bug in Chrome [06:10:40.0000] annevk: oops. Missed that 2018-08-13 [22:36:53.0000] TabAtkins: so CSS Paint having side channels seems like a big problem? I guess it depends a bit on what it gets to paint, but anything sensitive will have this issue [22:45:12.0000] We don't have anything sensitive exposed to selectors besides :visited, and I opened an issue to solve that part once and for all. [22:45:37.0000] The side channel is just a timing attack; there are multiple ways to achieve that, Paint is just higher bandwidth [23:47:30.0000] Well from that issue it seems like there is a communication channel [23:47:42.0000] With width [23:48:34.0000] Which would allow fingerprinting of CSS paint impl specifics and such [23:59:19.0000] smaug____: It doesn't look: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/document.h?q=KLoadListener&sq=package:chromium&g=0&l=863 [00:00:52.0000] smaug____: However, maybe I am not aware. I am aware only the list in document.h. [02:06:21.0000] k [02:06:30.0000] hayato: thanks. I'll keep debugging that bug [03:59:00.0000] Hello whatwg [04:53:29.0000] Hello author [06:57:01.0000] I suppose jyasskin is already on leave? I wonder if https://github.com/whatwg/fetch/issues/784 requires any action on my part at this point; I'm inclined to wait [07:08:39.0000] @annevk: I'm not quite out, although definitely by Wednesday. But #784 doesn't need anything for now, unless you want me to handle the monkeypatches in WICG/webpackage#281 differently. Even that can probably wait until I get back in November. [07:11:50.0000] jyasskin: thanks, and success juggling both of them! [07:12:13.0000] :) [10:28:09.0000] foolip: MikeSmith: we should do TLS 1.3 [10:28:11.0000] https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/ [10:30:19.0000] I have a feeling that will require bleeding-edge nginx extensions [10:31:53.0000] yeah there's very little supporting TLS 1.3 at this point [10:59:28.0000] annevk: if Domenic is right that would require more complicated setup, ot perhaps upgrading Debian [11:00:35.0000] ekr or davidben are likely to know for sure. [11:09:39.0000] foolip: what debian version are we on right now? [11:11:20.0000] Domenic: omg, do you have do the the `.X\58X` thing in the stylesheet to avoid it getting blocked by filters? [11:11:56.0000] (context for others: https://github.com/whatwg/html/pull/3911/files#diff-36cd38f49b9afa08222c0dc9ebfe35ebL87) [11:12:37.0000] TimothyGu: I'd have to log in to check, but I think stretch [11:12:47.0000] ah [11:13:08.0000] TabAtkins: i'm not sure what filters you mean, but iirc the html build system complains about "XXX" (so it can be used to mark unfinished work) [11:13:37.0000] that or it was used to track actual issues [11:13:38.0000] Ah, kk. I'm referring to braindead internet filters that block pages that contain strings that indicate porn or similar. [11:14:19.0000] ah yeah it's not that 2018-08-14 [17:21:23.0000] What's the best way to edit a commit description for a pull request that hasn't yet been merged? I recall seeing that just editing the pull request description doesn't help the person doing the merge, and it's preferred that the first commit have a good description. [17:25:07.0000] falken: `git commit --amend .` on the PR branch? [17:28:39.0000] TimothyGu: yeah stretch [17:30:48.0000] MikeSmith: Thanks [17:33:04.0000] TimothyGu: stretch-backports has nginx 1.13, which apparently includes TLS 1.3 support https://ma.ttias.be/enable-tls-1-3-nginx/ [19:50:05.0000] Yeah I'm not sure the XXX for unfinished work filter is all that useful; we may want to just remove it [21:56:29.0000] falken: for WHATWG PRs you can also leave a comment with a proposed commit message [21:57:11.0000] falken: we typically use squash & merge anyway [22:26:42.0000] annevk: thanks [02:09:15.0000] hmm, I guess I should start to look at tpac schedule and such [02:11:37.0000] smaug____: I hope you registered for the discounted rates? [02:22:46.0000] I didn't [04:53:20.0000] Fun with different rendering http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6088 [07:07:29.0000] zcorpan: https://docs.google.com/document/d/1JM0YmKNRmhl1nEqcg_M_KlxBg_q7LIz9xgzmbrHp34o/edit seems quite nice if we can make that work [07:07:46.0000] zcorpan: it roughly matches what I proposed long ago, except mine had display values [07:08:07.0000] zcorpan: perhaps with an actual draft specification that includes a bunch more details implementations will this time around be compelled to go for it [07:08:09.0000] annevk: yeah. web compat requires most display values to be ignored [07:08:47.0000] i hope so [07:09:04.0000] zcorpan: one thing we could do for now is to just say these are !important styles in the UA style sheet [07:09:25.0000] zcorpan: if impls are not willing to make it swappable [07:09:45.0000] (plus I guess some other magic so you can't use it elsewhere) [07:10:27.0000] annevk: an important property is to be able to turn it off ^_^ i'd specify it differently if it's supposed to match how it's implemented now [07:14:02.0000] I'm trying to identify browser developers who can fix fieldset bugs, not much luck so far [07:18:17.0000] zcorpan: I wouldn't hold out hope of that all coming together within 30 days [07:18:59.0000] At least I can try :) [07:19:45.0000] zcorpan: success to me would be something that describes and improves upon the status quo + tests, and various bugs against browsers for the improvements, and being able to close the existing whatwg/html issues [07:20:10.0000] zcorpan: but yeah, if we could get that too 😊 [07:35:36.0000] annevk: do you recall anything mouseenter/leave specific event dispatch handling when target is in shadow DOM [07:39:39.0000] smaug____: no [07:46:45.0000] ahaa, this indeed very much smells like a blink bug [07:46:45.0000] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/input/boundary_event_dispatcher.cc?gsn=SendBoundaryEvents&l=76-79 [07:46:49.0000] hayato: ^ [09:28:35.0000] Hello, I have a question [09:28:52.0000] Why does the project that aims at building HTML [09:29:05.0000] ... have the worst looking website ever? [09:29:10.0000] has* [10:23:07.0000] Not much of a question if you can't wait around for the answer... [10:28:39.0000] is there some code indexing tool for webkit? [10:31:58.0000] smaug____: nothing quite like searchfox [10:32:33.0000] smaug____: there's https://trac.webkit.org/ but I guess you know about that [10:32:45.0000] yeah, that I know about. It isn't really indexing tool [10:33:00.0000] Yeah, it's slow too [10:33:41.0000] smaug____: perhaps you can convince Bill to add WebKit to searchfox? [10:34:53.0000] would feel a bit odd if Mozilla provided the only useful code indexing tool for webkit :p [10:35:35.0000] smaug____: it'd be useful though [10:36:16.0000] I think there was some interest to get it added to cs.chromium.org too (but not enough interest to make it a thing) [10:37:16.0000] Basically I often want to quickly check how things are implemented to verify assumptions and in practice I end up ignoring WebKit due to it being so bad at this [10:50:10.0000] The GitHub mirror is at least better than trac [10:50:20.0000] somehow usability of cs.chromium.org is quite far from searchfox [11:58:45.0000] Domenic: GitHub search does not search commit messages though, right? [11:59:03.0000] Yeah I guess not. Does trac? [11:59:33.0000] I think so, but with trac code search is bad [13:13:22.0000] If I did, beleive me, the UI would be there immediately. [13:13:40.0000] Sorry, accidental history re-post. [15:19:46.0000] annevk: github search does search commit message [15:20:00.0000] https://github.com/whatwg/html/search?q=empty&type=Commits 2018-08-15 [20:14:15.0000] It occurs to me that we could replace our homepage motto with https://twitter.com/hsivonen/status/972410642446585856 [22:40:14.0000] Domenic: Do ittttttttt [23:03:53.0000] TimothyGu: cool [02:22:23.0000] If someone is still waiting on me for something, please tell me [02:23:16.0000] (minus a couple HTML PRs I guess, looking at those now) [03:10:26.0000] Can someone with an OS other than macOS test this https://bug474415.bmoattachments.org/attachment.cgi?id=357809 [03:10:29.0000] in firefox [03:10:57.0000] zcorpan: BrowserStack ok? [03:11:07.0000] sure [03:11:21.0000] I can do Fx 62 beta on Windows 10 [03:11:28.0000] want to know if the fieldset has the same vertical alignment as the surrounding text [03:12:08.0000] zcorpan: renders identically [03:12:15.0000]