Page MenuHomePhabricator

Handle edit conflicts on the mobile app in some way
Closed, ResolvedPublic


Currently, the app silently saves and writes over other edit without notifying about conflict.


Version: Android App 2.6.201-beta-2017-08-10 (but it's been broken a while before that)


Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:11 AM
bzimport set Reference to bz64281.
bzimport added a subscriber: Unknown Object (MLST).

Currently we just ignore Edit Conflicts and just overwrite the conflicting edit. This is 'bad' and we should get to have some way of both:

  1. Letting the user know that a conflict has occured
  2. Some way of resolving it
FriedhelmW triaged this task as Unbreak Now! priority.Feb 16 2015, 2:42 PM
FriedhelmW updated the task description. (Show Details)
FriedhelmW set Security to None.
FriedhelmW added subscribers: Aklapper, FriedhelmW.
Deskana lowered the priority of this task from Unbreak Now! to Medium.Feb 16 2015, 3:47 PM
Deskana added a subscriber: Deskana.

Don't panic! This is a normal priority issue. :-)

How is this just normal priority?

@Krenair We're focussing on reading and not actively supporting editing right now, and also this is a nontrivial issue to fix.

Honestly I don't see why clients should even be allowed to just ignore conflict detection like this. Perhaps it's an upstream MediaWiki-API issue.

Hi Guys,

IMHO this is a serious show-stopper. It is very embarassing to commit an edit conflict without even being noticed.
Please implement at least a simple fix soon, like showing a message like "Sorry, your edit cannot be saved because the page has been edited by another user". Possibly give the user a chance to copy their own text into system clipboard, but even completely throwing away the user's edit is better than an unnoticed edit conflict. Sophisticated stuff like merging text may be implemented later ...

This happened using Android 2.1.141-fdroid:

No progress here since 2014? IMHO it's irresponsible to keep the application like this. If you can't fix it, please disable editing in the mobile app completely.

clel added a subscriber: clel.Jun 20 2017, 5:11 PM

Just adding a comment to (hopefully) give this more relevance.

atgo updated the task description. (Show Details)Aug 15 2017, 8:00 PM
atgo added a subscriber: jeremyb.
jeremyb updated the task description. (Show Details)Aug 16 2017, 3:40 PM
jeremyb raised the priority of this task from Medium to Needs Triage.Aug 16 2017, 3:43 PM

Don't panic! This is a normal priority issue. :-)

@Deskana no, this is absolutely not normal priority.

I'll defer to others on getting this more perfect/polished but for now at least making it fail instead of silently clobber other's changes without telling anyone that there was an edit conflict is IMHO high/UBN.

jeremyb triaged this task as Unbreak Now! priority.Mar 21 2018, 7:00 PM

enough is enough. silent data loss is not ok. IMO we should disable all editing from this app until this task is resolved.

(that was with Android App 2.7.225-beta-2018-02-06)

do I have to fix it myself? (currently a snow day, not entirely joking)

but seriously regardless of how it gets fixed now how did this go nearly 4 years without resolution? in T66281#1123593 @Deskana says this is a nontrivial issue to fix. can you elaborate?

Restricted Application added subscribers: Liuxinyu970226, Mholloway, TerraCodes. · View Herald TranscriptMar 21 2018, 7:00 PM
jeremyb added a comment.EditedMar 21 2018, 7:06 PM

I'm not even saying make it perfect, but MVP

  1. no silent error, no clobbering, if there's a conflict then don't make the edit. and also pass the server enough data so that it is possible for it to do the server side conflict resolution magic
  2. but also no data loss client side. give the user an opportunity to copy the text that they were trying to save. possibly to clipboard or a share to another app.

note, that initial fix does not require any kind of local display of a diff or display of the server's version. that can be a future enhancement but the 2 points above are absolutely UBN.

Dbrant lowered the priority of this task from Unbreak Now! to High.Mar 21 2018, 7:36 PM
Dbrant added a subscriber: Dbrant.

Acknowledged, and will move into our next sprint. However, the "mvp" solution will need to be something like the following:

  • It looks like we can easily detect whether an edit conflict has occurred, by including the timestamp of the last revision, as the API specifies.
  • We can also show an error to the user when they try to submit the edit (and don't actually submit the new edit).

However, doing anything beyond that (e.g. showing a diff) will indeed take significantly more work, and is not on the current road map.

In the interest of preventing data loss on the client side, we can instruct the user to copy the changes they've made to the clipboard, then go back to the article, refresh it, then edit it again.

It sounds like the biggest issue here is the silent "clobbering" of edits that can be made currently from the app, which would be mitigated by the mere detection of conflicts. Is that correct?

Is that correct?

there should be no data loss client-side nor on-wiki. but sounds like your comment just repeated what I already said so we're on the same page.

Change 421141 had a related patch set uploaded (by Dbrant; owner: Dbrant):
[apps/android/wikipedia@master] [WIP] Correctly handle edit conflicts.

@RHo : When there is an edit conflict, we advice the user to copy content and go back and refresh, and then when the user tries to exit, we still show the dialog asking the user to save changes. If we should not show that dialog once we show the conflict dialog, could you please open a ticket for that? :

Change 421141 merged by jenkins-bot:
[apps/android/wikipedia@master] Correctly handle edit conflicts.