[15:28:39] duesen: question about edit conflicts in the API, if you have a moment: https://phabricator.wikimedia.org/T246726#5954012 [15:39:50] MatmaRex: i replied there [15:39:56] thanks [15:41:19] MatmaRex: basically: ignoring self-conflicts is nota bug, it's a feature! I'd be very happy if we could kill it, but apparently, someone at some point decided we need this for some reason [15:42:18] yeah… [15:43:06] MatmaRex: do you know why? I'm recalling tehre being some odd reason, btu I can't remember what it was [15:43:21] James_F: I vaguely recall you chiming on on the discussion about this... do you recall why we ignore self-conflicts? it seems like a bad idea [15:43:46] duesen: uhh, i've read on one of the tasks that it's meant to help if you press Back in your browser after saving changes [15:44:06] which opens the editor for the old revision, but with the new revision's contents in it (if your browser restores them) [15:44:16] how does it help, though? it seems to me it would only help to override your edit [15:44:55] dunno, i just read that, haven't tested it [15:44:57] here: https://phabricator.wikimedia.org/T175745#3602110 [15:45:45] "Yeah Netscape 4 days" [15:45:49] ah thanks [15:46:57] duesen: i think it would still work the same way. but maybe editing in multiple tabs is more common these days than going back [15:47:20] and also, the new edit conflict screen makes edit conflicts a lot less rage-inducing [15:54:05] MatmaRex: not for me, when i hit "back", the browser re-loads the edit page, so it gets the new base id and edit times in the hidden form fields. no edit is detected even if i comment out the special case code [15:54:17] I'll comment on the ticket to this effect. [15:54:54] duesen: all kinds of JS stuff probably messes with the normal browser behaviors here… try doing that with JS disabled? [15:55:27] e.g. if you have the syntax highlighting extension enabled, i'm pretty sure that browsers won't restore the text input when going back [15:55:28] or VE [15:57:01] browsers definitely restore form inputs on back/forward navigation, i remember dealing with that when i was working on OOUI, and where infusing (rebuilding those inputs in JS) was breaking the browser behavior [16:02:23] Just tried with JS disabled [16:02:35] works correctly. the form is reloaded, not restored [16:03:13] MatmaRex: https://phabricator.wikimedia.org/T175745#5954122 [16:03:30] I would be extremely happy wif we could kill this. I has been bothering me for abotu eight years now. [16:04:31] huh [16:06:24] MatmaRex: try it. open the edit form, remember hte values of wpEdittime and editRevId. Save the edit, hit back, look at these values again. [16:06:51] Also: in EditPage, find the call to userWasLastToEdit. replace by false. Try editing, htting back, editing again. [16:47:57] duesen: i see the same behavior, but i don't understand why it is like this [16:48:07] (sorry, i was away for a bit) [16:49:47] duesen: with JS enabled, we use the 'beforeunload' event, and the spec: https://html.spec.whatwg.org/multipage/browsing-the-web.html says that this makes the document "unsalvageable". but i don't get why it's the same without JS [16:51:52] i love the specs sometimes. apparently during unloading, the browser must "make disappear" any web sockets [16:52:03] MatmaRex: cache control headers? or an intermediary redirect? [16:52:21] In any case - it'S the behavior we want, right? [16:55:07] yes. i would prefer to know why though. if it magically changed from the bad behavior ot the good one a few years ago (?), it can change back a few years from now [16:55:20] i'd go read the source code but i don't really have the time [16:58:48] duesen: hmm. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/1.5/Using_Firefox_1.5_caching "the page sets "cache-control: no-store"." [16:59:11] duesen: we indeed set that on action=edit, although i don't know where that happens [16:59:15] i see "Cache-Control: no-cache, no-store, max-age=0, must-revalidate" on my test wiki [16:59:37] that link has "firefox 1.5" in the name, which doesn't inspire confidence, but i can't find any better documentation [17:00:18] (brb meeting)