Follow mode stops when the followee deletes a file

[dpp-gerrit]

Steps: 1. Alice share project with bob 2. Alice create two files A and B 3. Bob follow alice 4. Alice delete B

Result: Bob is not in follow mode

Expected result: Follow-mode should remain until Bob decides otherwise.

Reported by: nudelfish

Original Ticket: dpp/bugs/469

[dpp-gerrit]

Bug - Analysis

Alice Analysis

The following extract of a logfile shows the acitivities on Alice's saros client after deleting a file. These informations are send to Bob. (The logextract was modified for better readability).

DEBUG 18:06:16,086 [Timer-0] (XMPPTransmitter.java:649) Sent (005)
argument1: [senderadresse@email.com/Saros2BA69C1D]
argument2: (Liste von dpp.net.TimedActivityDataObject)
[FileActivityDataObject(type:Removed, path: SPathDataObject [editorType=txt, path=src/A.java, projectID=1954960459])],
[EditorActivityDataObject(type:Activated,path:SPathDataObject [editorType=txt, path=src/B.java, projectID=1954960459])],
[EditorActivityDataObject(type:Closed,path:SPathDataObject [editorType=txt, path=src/A.java, projectID=1954960459])], ...

These lines explain what happens on Alice's side: 1. Because of the deletion of file A a FileActivity of type removed is generated. 2. After deleting the file Eclipse automatically activates the last opened editor (for file B in this case). Saros generates a related EditorActivity of type activated. 3. Just afterwards another EditorActivity of type closed is generated, because Saros notes that the editor of A has been closed.

Saros sends these activities to Bob - there are no recognizeable defects on alices side.

Bob Analysis

As soon as Bob is processing the first of the received activities, the defect occurs in class de.fu_berlin.inf.dpp.editor.EditorManager in method public void partActivated(IEditorPart editorPart).

This is happening while processing the FileActivity: 1. File A is removed due to the FileActivity. 2. Eclipse automatically opens the last opened editor (in this case editor for file B). 3. EditorManager.partActivated(...) is called by de.fu_berlin.inf.dpp.editor.internalEditorPartListener.partBroughtToTop(...)

Among other things the partActivated method checks wheter user Bob is in following mode. If he is, it is validated if the newly openend editor handles the same file like the person Bob is following (Alice). Because Saros hasn't processed the EditorActivityDataObject of type activated so far, it concludes that Alice still works with file A. The logical conclusion is that Bob intentionally has opened another editor and Saros terminates the following mode.

Here the relevant code snippet where the defect is noticed (r3670):

package de.fu_berlin.inf.dpp.editor
class EditorManager
public void partActivated(IEditorPart editorPart)

[...]

if (isFollowing()) {
    RemoteEditor activeEditor = remoteEditorManager.getEditorState(getFollowedUser()).getActiveEditor();

    if (activeEditor != null && !activeEditor.getPath().equals(editorAPI.getEditorPath(editorPart))) {
        setFollowing(null);
        // follower switched to another shared editor or closed followed
        // editor (shared editor gets activated)
        SarosView("Follow mode stopped!", "You switched to another editor \nor closed the followed editor.");
    }
}

If the user is in follow mode, the first if condition is true. The active editor of Alice is returned by remoteEditorManager of Bob. This leads to an inconsistency because Alices active editor is not updated to the correct file B before the following EditorActivty (type activated) is beeing processed. That's why the currently active editor of Alice still handles file A when the FileActivity is processed.

Defect solution approaches

To fix this bug we tried out three different approachs. Unfortunately none of them seem to solved the problem.

1. Approach: Changing the sending order of the relevant activities. The basic idea of this approach is that Alice sends the EditorActivies before the FileActivity. This would keep the state of the RemoteEditorManager consistent. It would mean that the receiver of the remote editor manager updates the active editor, before accessing it in the partActivated(...) method in the editor manager. Since, the activities are originally created by Eclipse itself, the transmission sequence can not be changed reliably. Thats why this approach fails.

2. Approach: Changing the order of processing the activities on receivers side. This approach is based on the creation of a new functionallity in the listener of the reciever. If we could detect such a file deletion sequence in the recieved XMPP packets we could postpone the FileActivity until the EditorActivities have been processed successfully. The problem with this approach is that we can not guarantee that all three activities are send together, so detecting the sequence is impossible in some cases.

3. Apporach: Transmission of the new opened file path within the FileActivity. Our last approach tackles the problem by updating the active editor on the recievers side while processing the FileActivity (not afterwards). We thought about doing this by including the path to the newly opened editor in the FileActivity itself. Unfortunately at the time the FileActivity is created, Eclipse has not yet decided which editor to open after the file has been deleted so this apporach fails.

Original comment by: corve010