07:34
<jochen__>
annevk: Hiroshige is refactoring those tests. Maybe they're temporarily broken or smth?
07:47
<mkwst>
jochen__: Yes. This test was broken by that refactoring. It's less broken now. :()
07:48
<mkwst>
Bakkot: I put it on my list for this morning.
10:04
<ondras>
@JakeA: figured out that spamming twitter might not be the best way. Perhaps you can forward me to someone in particular to solve my Lighthous issue here on IRC?
10:07
<JakeA>
ondras: best plan would be to file an issue on the lighthouse repo with a reduced example
10:07
<JakeA>
ondras: please send it my way too, I'm curious 😀
10:08
<ondras>
JakeA: it is a very simple static web/app with one html, one css and one js
10:08
<ondras>
JakeA: https://ondras.github.io/rri/
10:08
<ondras>
not sure whether this would work as a "reduced" example though :/
10:08
<ondras>
just tried installing chrome-unstable (81), still reports the weird non-sw response
10:09
<JakeA>
ondras: it's best to remove everything that doesn't contribute to the bug. You might find it isn't a lighthouse bug while doing that
10:10
<ondras>
yeah.
10:26
<ondras>
JakeA: I *think* I can see why the problem happens. It seems that the "offline" Lighthouse simulation does not limit the SW from performing a fetch. So even when in Lighthouse/offline, my SW performs a fetch (its strategy is online-first), returns the fetched data and this is considered "not returned from a sw"
10:41
<ondras>
@JakeA: reduced, published, submitted: https://github.com/GoogleChrome/lighthouse/issues/10237
10:53
<JakeA>
ondras: this is an A+ reduction! At a glance, yeah, it looks like Lighthouse is in the wrong
10:58
<ondras>
JakeA: thanks. Looks like people generally recommend returning a cached version, even with stale-while-revalidate...
10:59
<JakeA>
ondras: online-first is problematic, but it's better than online-only
10:59
<annevk>
So I change some srcdoc stuff with javascript in this referrer policy test and Firefox logs a different referrer and Chrome yields undefined
10:59
<annevk>
Good times
11:00
<JakeA>
ondras: if you've got a connection, but it's just hanging, it still leaves the user with a while screen until it times out
11:00
<ondras>
JakeA: should be solvable with a timeout
11:00
<JakeA>
ondras: that's a bit better, but it still means you have that timeout per request
11:01
<JakeA>
2 seconds for the html, then another 2 for the CSS and js, then another 2 for the data… even a short timeout can become a long delay
11:04
<ondras>
yes, the timeout would be a safety hatch, not a primary usage scenario
20:57
<smaug____>
Does some document explain mapping from ES spec language to things like microtasks
21:00
<smaug____>
Domenic: you might know
21:01
<Domenic>
smaug____: https://html.spec.whatwg.org/multipage/webappapis.html#enqueuejob(queuename,-job,-arguments)
21:01
<Domenic>
Or I guess https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-job-queue has a bit more background
21:02
<smaug____>
Domenic: ok, and how should one interpret https://tc39.es/proposal-weakrefs/#sec-clear-kept-objects
21:02
<smaug____>
"synchronous sequence of ECMAScript execution"
21:03
<Domenic>
No idea, seems like vague BS to me
21:03
<smaug____>
I couldn't find that kind of sentence in the es spec
21:03
<smaug____>
Domenic: ok, it felt like that to me too :)
21:03
<Domenic>
smaug____: ah it looks like https://github.com/whatwg/html/pull/4571/files is the actual intended integration
21:05
<Domenic>
smaug____: in particular https://whatpr.org/html/4571/webappapis.html#perform-a-microtask-checkpoint
21:05
<smaug____>
thanks
21:31
<andreubotella>
hey
21:32
<andreubotella>
the other day I opened my first bug on a standard, which turned out to be a good first issue, and I'd like to work on the PR
21:32
<andreubotella>
but I have a couple questions about the contributor agreement before I get started on it
22:25
<MikeSmith>
andreubotella: what are your questions
22:26
<andreubotella>
right
22:27
<andreubotella>
The agreement talks about getting your employer/client company to sign it if they work in "web technologies".
22:27
<andreubotella>
does that only mean browser developing, or does it extent to web dev too?
22:28
<MikeSmith>
andreubotella: it is unclear exactly what that term "web technologies" in the Participant Agreement means
22:28
<MikeSmith>
the agreement does not define the term
22:29
<andreubotella>
okay, so I guess I'll move to point 2 then.
22:29
<andreubotella>
I do web dev for a few clients, but I noticed and worked on this issue on my time.
22:29
<andreubotella>
I guess I don't need to have them sign, right?
22:29
<MikeSmith>
see https://github.com/whatwg/sg/issues/67
22:31
<MikeSmith>
if you are an independent developer working for clients, that "web technologies" requirement is not relevant
22:31
<MikeSmith>
your clients are not your employer, in the sense the agreement means
22:31
<MikeSmith>
you are your own employer
22:33
<andreubotella>
ok, I thought I understood it to refer to clients too
22:33
<MikeSmith>
no
22:33
<MikeSmith>
it doesn't, not to clients
22:33
<andreubotella>
ok
22:33
<andreubotella>
so that solves it
22:33
<andreubotella>
thanks so much
22:33
<MikeSmith>
cheers
22:34
<andreubotella>
is there any process to go about working on the issue, other than just saying I'm working on it in a comment and then linking to the bug in the pull request?
22:35
<MikeSmith>
just saying in a comment that are you working on it is fine
22:35
<MikeSmith>
but if you want, you can also ask the spec editor(s) to assign the issue to you
22:35
<andreubotella>
right
22:35
<andreubotella>
thanks so much
22:35
<MikeSmith>
no problem
22:36
<MikeSmith>
thanks for working on stuff
22:36
<andreubotella>
sure
22:37
<andreubotella>
I read a lot of web standards, and the ambiguity in terms between code points and scalar values in Encoding was bugging me
22:37
<andreubotella>
and then I noticed some security implications
22:37
<andreubotella>
so that's the least I could do
22:38
<MikeSmith>
ah cool