Bug 498298

Comment 1 Matthias Wienand 2016-07-21 12:40:14 EDT

Currently, the ContentBehavior performs a content synchronization before flushing the SelectionModel and the HoverModel. After the synchronization, a removed content part can still find a link to the viewer via corresponding feedback or handle parts. However, after flushing the models, the feedback and handle parts are removed from the root part before they are detached from the content parts. Therefore, the feedback or handle parts lose their link to the viewer as soon as they are removed from the root part, but the content parts cannot find a link to the viewer when their anchoreds (feedback and handles) are removed, because they could previously find the link only via their anchoreds. Hence, in some situations, removed content parts are not unregistered from the content-part-map.

In order to resolve the issue, we should ensure that a content part cannot find a link to the viewer via feedback or handle parts. The corresponding methods that need to be adjusted are AbstractVisualPart#getRoot() and AbstractVisualPart#determineViewer().

Comment 2 Matthias Wienand 2016-07-22 09:13:23 EDT

For now, I ensured that the content parts are unregistered from the content-part-map by changing the order in which feedback and handles are removed and detached, respectively.

The default behaviors use the BehaviorUtils#addAnchoreds() and #removeAnchoreds() methods for adding and removing feedback and handles. The latter is responsible for detaching the anchoreds from their anchorages, as well as removing them as children from the root part. By detaching the anchoreds frist, the anchorage content parts lose their link to the viewer but can still reach the previous viewer because the removed anchoreds can still navigate to the root part.

The code is published on the master and R4_0_maintenance branches. However, I will keep this ticket open until the underlying problem is resolved.

Comment 3 Matthias Wienand 2016-09-05 06:58:52 EDT

I changed the AbstractVisualPart#determineViewer() and #getRoot() methods so that anchored feedback and handle parts are skipped. The code is published on the master branch, and was backported to R4_0_maintenance. Therefore, I resolve this issue for 4.1.0 RC3 / 5.0.0 M2.

Comment 4 Alexander Nyßen 2016-12-13 05:29:20 EST

While the behavior was reported to be necessary for content parts only, the code has been added to AbstractVisualPart. We should check whether this restriction is still needed after the content synchronization has been centralized.

Comment 5 Matthias Wienand 2016-12-13 09:34:54 EST

The centralization of the content synchronization was accompanied by separating the synchronization into four different phases which are performed after each other: 1) detachment, 2) removal, 3) addition, 4) attachment. Therefore, all parts are inserted into the part hierarchy (as children) before they are attached to their anchorages (as anchoreds).

Prior, the attachement was done for each part separately after it was inserted into the part hierarchy. This led to anchorages being constructed before they are inserted into the part hierarchy. Then, the only way for these anchorages to reach the viewer was via their anchoreds.

However, now that the addition and attachment phases are separate, a part should never have to access its anchoreds to reach the viewer, but should always be able to reach it via its parent chain.

Therefore, the code that determines the root part and the viewer does not need to try to find them via the anchoreds of the part, but can rely on the part hierarchy for accessing both.

Consequently, I removed the special cases within AbstractVisualPart#getRoot() and #determineViewer(), respectively. The code is published on the master branch, therefore, I resolve this ticket as fixed for 5.0.0 M4.