| 03:56 | <Krinkle> | zcorpan: Domenic: Thanks, that helps :) - downstream ticket is https://phabricator.wikimedia.org/T266708 |
| 03:56 | <Krinkle> | (: TypeError: document.head.appendChild is not a function) |
| 03:57 | <Krinkle> | Received regularly albeit at a low frequency on en.wikipedia.org from Mobile Safari |
| 04:00 | <Krinkle> | document not being Document seems unlikely given the diversity of clients, but given we do support greasemoney-style user scripts within the platform, that might still be a possibility. I'll see if I can find reports from users without a login session to rule that out. |
| 04:01 | <Krinkle> | iframes might be it, we don't do that in our own code afaik, I can't imagine why, but again it's possible a user script might do that as a hacky way to accomplish some legacy thing without using the API through some kind of headless simulation of a user action for an automated/assisted editor workflow. |
| 06:13 | <annevk> | Might also wanna check when WebKit added document.head support |
| 12:59 | <hsivonen> | TIL: Safari is intolerant of https://hsivonen.com/test/ . It's OK with nginx serving flat files, it's OK with nginx proxying Jetty. Not OK with nginx proxying Apache. |
| 13:11 | <annevk> | Surely it's not the server but something particular in the response? |
| 13:11 | <annevk> | Anyway, I'd recommend filing a bug as they probably want to address that |
| 23:27 | <MikeSmith> | https://stackoverflow.com/questions/64671178/scroll-event-not-fired-in-chrome-when-document-hidden-is-true-any-workarounds |
| 23:28 | <MikeSmith> | > The scroll event is never fired by Chrome when the page is hidden, despite the page is actually scrolling. That looks like something they implemented to reduce cpu and network usage for pages that are not visible. |
| 23:28 | <MikeSmith> | is that behavior spec-conforming? |