[04:18:41] Krinkle: the comment on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/615869/1/includes/libs/rdbms/loadbalancer/LoadBalancer.php still needs addressing [08:31:59] Krinkle: there's one thing that isn't working correctly that I haven't fixed yet in https://phabricator.wikimedia.org/T249686 [16:15:11] FYI Linh didn't respond to my email when I asked her to move the meeting with Grant a couple of days ago [16:15:49] I guess we can try to keep it short and then join late? [16:16:00] yeah, let's try to do that [16:32:19] https://diff.wikimedia.org/2020/09/08/making-programs-events-dashboard-faster-on-slow-connections/ [16:46:17] Krinkle: is it a bug that you can generate non-js wiki pages as Js? https://en.wikipedia.org/w/index.php?title=&action=raw&ctype=text/javascript [16:46:31] (for main page) [16:46:45] no, that's fine. [16:47:03] anyone can create JS pages and serve them publicly [16:48:22] we could disallow it based on revision content model, but that requires various tech debt to be prioritised first to finish migration and use cases in the wild for storing js under non-.js pages and vice versa [16:48:43] but security wise or otherwise, it's not significant and is how the code is written [17:02:19] thanks [21:14:56] Jdlrobson: so I did some digging, I was half-convinced that document.body being undefined is a WebKit/Safari bug as I recall the spec very specifially requiring things like document.head and documetn.documentElement to always exist, if not explicitly then implicitly. That is to say, when you write you'll get null, and that's consistent across Chrome/Firefox/Safari . [21:17:36] that still doesnt' explain how it can be that an async script in the last few bytes in before manages to load, parse and exec before , but at least it's not technically a browser bug.