Issues with track changes
From an EaaS user:
A new report for you today. Our editor working in chapter 7 of ****** on our Editoria instance (in current version of Chrome) has reported a problem reminiscent of some of our more serious past bugs. She had been making minor tracked changes to the text and then hit “Hide Changes” so as to better read through the flow of the paragraph as revised. She then made a couple of additional adjustments to the text, hit “Show Changes”, selected the text of the whole paragraph, and clicked “Accept.” This is the same procedure she has used successfully through other chapters. On this occasion, however, the result was unexpected. Where normally this procedure results in the application of all tracked changes to the paragraph, producing a final paragraph identical to the one seen with “Hide Changes” on, she instead found that all of the author’s proposed deletions had been removed (as expected), but that some of the author’s proposed additions had not been applied to the text. The result was ungrammatical lines incorporating partially applied changes and aberrant letters, with formations like “which.h”. She then hit the “Undo” button in the toolbar to revert the acceptance of changes (again, a normal procedure for her), but the button produced no response. She pressed it again and the tab froze, generating a repeating browser notification prompting her to choose to wait for the tab to become responsive or close it. She elected to wait through a couple of cycles until the page became responsive, but found the response sluggish. She manually re-applied such of the lost changes as she could remember and hit save before the tab again froze and prompted her, whereupon she selected to close the tab. An additional anomaly noticed in the chapter while troubleshooting the above, which may or may not be related, involves visual artifacting in comments. Attached is a screenshot taken during the troubleshooting where you can see, toward the bottom of the screen, a comment erroneously reduplicated (as per our previous report of that phenomenon) in which the top comment displays normally while the lower one is stuttered.
I also observed two comments overlapping each other in another location, though this was resolved by opening the reply thread of the top one. I personally encountered another unexpected behavior in chapter 10 yesterday that likewise may or may not be relevant to diagnosis here. While making tracked changes to the text, I attempted to backspace over my own proposed change to make an alteration. One letter, however, refused to be deleted. I could neither backspace over it, nor highlight and replace it by typing. It could only be removed by “rejecting” the change. I mention this only in case it is usefully diagnostically. Owing to the concerns this raises about potential loss of data, we accord the issue of lost changes and lost tab responsiveness in chapter 7 a high priority. Thank you!