FM 2020. Ditamap occasionally rolls up/down when using cursor or backspace in dita file.

[Ian16B7]

I am using Framemaker 2020, (16.0.1). Dita 1.3.

The following problem only happens occasionally, and I am not clear on the pattern of what causes it.

Occasionally, when I have a ditamap and dita file open and am trying to edit it, the following behaviour occurs, which slows down editing the dita file to a very frustrating level:

• Every cursor move (left, right, up or down) in an open dita file results in the tree of the ditamap to roll up (i.e. all nodes close) and then roll back down (i.e. nodes previously open will re-open). 
• Same behaviour for backspace or delete in the open dita file
• Typing in letters, does not cause this behaviour in the ditamap.
• When the ditamap is rolling up and down, two additional things happen:
• there are changes to which dita files are highlighted in the ditamap
• The up/down/left/right arrows in the ditamap toolbar change in terms of which of these arrows are highlighted (I suspect that these changes reflect the differences in which dita file is highlighted.

Thus, it appears that cursor movements in a dita file are sometimes affecting both the dita file and the ditamap. 

Other interesting observations:

• When this error starts to happen, it affects all dita files in a ditamap
• If the ditamap roll-up/roll-down happens when a dita file is opened from the ditamap, then this error will occur. However, if the ditamap roll-up/roll-down does not happen when a dita file is opened, then the error will not occur (i.e. cursor moves will function correctly).
• Re-starting FM does not change this behaviour.
• It is possible for a ditamap to go from behaving correctly to behaving in this error condition and back again. I am not yet clear what triggers these state changes.
• If this error occurs, then it appears that I can cause the system to change back to a “good” state in which the error does not occur, by doing the following:
• Minimize the nodes in the ditamap
  • At this point, the ditamap will unroll once
• Click back in the dita file that was causing a problem, and click on a cursor key 
  • At this point, the ditamap will start behaving correctly
• Saving the ditamap at this point will result in the ditamap behaving correctly the next time that it is opened
• If a given ditamap is showing the error behaviour, saving the ditamap will cause the error to be present the next time that the ditamap is opened.

Possible underlying cause;

• I compared the underlying .XML code using a text editor between a ditamap that worked and one that did not. The only obvious differences was <Collapsed Yes> in the ditamap that did not work, and <Collapsed No> in the version that did work.
• I tested whether this XML tag was potentially causing the problem via the following:
• Test #1: I took a ditamap that did not work, manually changed the .XML file to <Collapsed No> using a text editor, opened in Framemaker and the error was gone.
• Test #2: I took a ditamap that did work, manually changed the .XML file to <Collapsed Yes> using a text editor, opened in Framemaker and the error was present.

[Pulkit-N]

Hi @Ian16B7 

I read your issue and understand your concern, To understand more clearly it would be great if you share some screen video which shows the given error.
You can add it here or mail me at punagpal@adobe.com .

-Pulkit Nagpal
-FM Engg.

[Ian16B7]

Thanks for the quick reply Pulkit. I will email you a video of the error.

Some further information - this error only happens if the ditamap was saved as a MIF 2020.

[Ian16B7]

Further update on file formats affected. I have now encountered this bug both with MIF2020 ditamaps and XML type ditamaps. However, there is a difference. The MIF2020 filetype will save the the ditamap in an unhappy state so that when re-opened, the ditamap will still exhibit this buggy behaviour. However, I have now observed this buggy behaviour in a XML filetype. I am still uncertain of the exact reproduction steps to get this problem to occur, but the above steps of "minimizing nodes" appears to "fix" the problem (which is frustrating if you happen to have a lot of nodes expanded).