[02:07:34] just spent about an hour drafting a CR comment for legoktm's https://gerrit.wikimedia.org/r/#/c/384930/21 and then gerrit lost it [02:07:54] oh no :( [02:08:30] I'll rewrite it after lunch, it's still in my head [02:09:43] ok :) maybe...not in gerrit :P [02:23:50] does gerrit need storage stuff like Phab has? [02:24:11] maybe at least in-browser local storage [02:24:36] * bd808 is not volunteering to figure out how to do that [03:30:50] I think Phab stores draft server-side actually. [03:31:10] I've noticed on more than one occasion that in a different browser or device, I navigated to an old task and noticed a pre-filled comment from long ago [03:31:17] Maybe happens as part of the live preview rendering [03:32:10] Gerrit does it server-side as well, but only after closing the text area by pressing "save" in the draft comment box [04:03:08] it was a whole changeset comment, not a line comment [04:03:23] the box disappears when you even try to scroll the window, but you assume it will come back afterwards [05:43:37] * - Shell::SECCOMP_DECAY : As the process executes, once per second, a syscall is randomly selected from the list of functioning syscalls, and is disabled. After 394 seconds, all syscalls are disabled. At the 395th second, the process is terminated with SIGKILL. [05:43:51] just a feature idea for legoktm [17:38:40] anomie: Sync'd your page_is_new fix live. Thanks for that -- was just about to file a task [17:38:51] Oh, there was a task, hah [17:40:07] anomie: is https://phabricator.wikimedia.org/T164900 resolved since you already deprecated it? [17:40:35] no_justification: I figured you'd have started seeing messages about it [17:42:12] Indeed, I was :) [17:42:13] legoktm: Hmm. I suppose it could be closed, yeah. [21:42:21] "Until T176693 is fixed, needs something like F9823771 applied to hyperswitch for the Swagger interface to work." -- commit messages can be full of gibberish :) [21:42:21] T176693: Cannot override basePath in the Swagger spec - https://phabricator.wikimedia.org/T176693 [22:41:39] anybody knows what is our support matrix with regard to Javascript? I.e. can I use ECMAScript 6 ? [22:41:57] no, ES5 is minimum [22:42:04] SMalyshev: see https://www.mediawiki.org/wiki/Compatibility#Browsers [22:42:10] darn [22:42:14] legoktm: thanks! [22:43:35] would it be super-bad if the bugfix works only in ES6 browsers while bug remains unfixed (though no other breakage) in ES5- ones? [22:44:03] I guess we could use a transpiler? [22:44:44] there's a module that implements the same function on lower browsers but then I'd have to figure out how to load it etc.. which turns one-line fix into a project [22:45:11] unless the problem is already solved... do we do unicode normalization anywhere? [22:45:35] I mean in Javascript of course [22:45:43] link to the bug? [22:46:20] legoktm: https://phabricator.wikimedia.org/T170779 [22:46:53] basically we compare two unicode strings without normalization, which is Wrong (TM) [22:48:03] ES6 has String.norlaize() which should solve the issue [22:48:07] *normalize [22:49:21] maybe Krinkle or James_F knows how we do normalization client-side? server-side we use the utfnormal library [22:49:47] yeah I found the php part but doesn't help me here :) [22:49:59] SMalyshev what about https://github.com/walling/unorm ? [22:50:02] there is this one: https://github.com/walling/unorm [22:50:22] paladox: yes :) but I'd need to add it to the build etc [22:50:30] ok :). [22:50:31] much more work than one-line fix otherwise :( [22:50:35] oh