@Nnemo: The mobile Web wikicode editor of Wikipedia is not really a page. It's actually just an overlay that is constructed via Javascript that sits on top of the regular article. This overlay is reconstructed via Javascript if you leave the page and come back (since it's not actually part of the real page). This has the disadvantage (compared to desktop) of losing your work if you leave the editor, but it has the advantage of avoiding merge conflicts if you launch the editor, leave, and come back later. Since merge conflicts are very difficult to resolve in a mobile interface, this is probably a good trade-off. Regardless, you should always get a warning in the mobile editor if you try to leave, saying "Do you really want to abandon your edit?". Did you get this warning when you left the page?

@kaldari, thank you for investigating this issue.

In T88949#1026713, @kaldari wrote:

Regardless, you should always get a warning in the mobile editor if you try to leave, saying "Do you really want to abandon your edit?". Did you get this warning when you left the page?

No.

I think that we can have the best of both worlds. A form with real-time AJAX stuff can be at the same time a standard static form. This is even necessary for accessibility.

@Nnemo Actually it looks like the behavior I was describing only applies if you hit the back button while in the editor. If you leave the editor by entering a new URL or loading a bookmark, there is no "Do you really want to abandon your edit?" alert. However, if you leave the editor by entering a new URL or loading a bookmark and then hit back to go back to the editor, all your edits should still be in place. I tried navigating several pages from the editor and then going back and it still had all my edits in place. I imagine if you exhausted your browser cache while navigating elsewhere you would lose your edits (as it would have to reload the page), but that's an edge case. (Tested in mobile safari.)

@Florian Can you reproduce this bug?

Can reproduce this in mobile chrome for android, same for chrome desktop. The page reloads instead of loaded from cache. In Firefox on desktop, i can see the bahaviour described by @kaldari, i can navigate to another site and go back and have the editor with my edits :/

I think for the first step we should ask the user, if he really want to leave the page, we an not guarantee, that the edit is saved in the browsers cache.

Change 190163 had a related patch set uploaded (by Florianschmidtwelzow):
Ask the user if he want to leave the editor

https://gerrit.wikimedia.org/r/190163

Patch-For-Review

In T88949#1033030, @kaldari wrote:

@Nnemo Actually it looks like the behavior I was describing only applies if you hit the back button while in the editor. If you leave the editor by entering a new URL or loading a bookmark, there is no "Do you really want to abandon your edit?" alert. However, if you leave the editor by entering a new URL or loading a bookmark and then hit back to go back to the editor, all your edits should still be in place. I tried navigating several pages from the editor and then going back and it still had all my edits in place. I imagine if you exhausted your browser cache while navigating elsewhere you would lose your edits (as it would have to reload the page), but that's an edge case. (Tested in mobile safari.)

From the JavaScript editor, I go to two other pages and I go back. Whatever pages I choose, this always makes me lose my text. When I do the same scenario from a standard form, my text is kept.

Adding the alert "Are you sure ?" would be a good move. However, even with the alert, I would still have been confident and I would still expect my text to be kept. With a standard form, like the plain old Wikipedia wikicode editor, overriding the alert, loading two other pages and then coming back give back my entered text, this is a standard behaviour of Web browsers.

Change 190163 merged by jenkins-bot:
Ask the user if he want to leave the editor

https://gerrit.wikimedia.org/r/190163

In T88949#1042110, @bmansurov wrote:

@Nnemo, since the editor is constructed on the fly without extra work to save the user's changes, the default browser behavior doesn't apply here.

That is the main part of the issue.

The editor could be a solid form in the page, and thus the browsers would keep the user data in it.

Should that be handled in a new separate task instead? Just wondering...

@Aklapper, I agree it should be a separate task with new designs from the design team. Pinging @MSyed.

@bmansurov: Then could you create a new task and close this task.

I have been waiting for an input from @MSyed and @Nnemo.

I am not sure about what exactly some people want as a new task. It seems to me that this new task would just describe one technical solution to the functional problem described here. So it would be simpler to just handle it here.

ehm, why did MF not reuse http://git.wikimedia.org/blob/mediawiki%2Fcore.git/093bb2e23e7a984eee9c32be79058c6e6974a740/resources%2Fsrc%2Fmediawiki%2Fmediawiki.confirmCloseWindow.js ?

Whether it is a JS overlay or an actual page makes no difference as we can use localStorage. Confirm exit windows do not work everywhere. There are lots of caveats. Also in mobile browser a lot of the time it doesn't get triggered - windows tend to stay open. I'm not convinced the library @TheDJ points at will work in mobile.

Personally I think remembering the text in the form is probably a bad idea.. the issue is knowing when to invalidate the cache and refresh the content. This is a can of worms which opens us up to edit conflicts due which in my opinion are much worse for the user...

@Jdlrobson, I should have clarified that my comment was specifically meant towards this patchset: https://gerrit.wikimedia.org/r/190163, which to me looks almost identical to the core module (but without some of the safeguards required for setting a listener on beforeunload

I see... That's the first time I've seen that patch. @bmansurov @Florian that should be fixed... That sort of code should be reusable.

I'll look into it :)

T94194

Change 200178 had a related patch set uploaded (by Florianschmidtwelzow):
Add mobile target for mediawiki.confirmCloseWindow

https://gerrit.wikimedia.org/r/200178

Change 200179 had a related patch set uploaded (by Florianschmidtwelzow):
Use mediawiki.confirmCloseWindow

https://gerrit.wikimedia.org/r/200179

Change 200178 merged by jenkins-bot:
Add mobile target for mediawiki.confirmCloseWindow

https://gerrit.wikimedia.org/r/200178

Change 200179 merged by jenkins-bot:
Use mediawiki.confirmCloseWindow

https://gerrit.wikimedia.org/r/200179

We don't work on another solution, here, right? So this can be closed? :)

The issue is not resolved.

@Nnemo: What do you mean with this? If I want to leave the wikitext editor, I'll get a message, that this will result in a loose of my edits, which I haven't saved, yet. Like I said above, we don't work on a nother solution :)