Re: Backward compatibility or valid input

On Fri, 2017-05-12 at 18:20 +0100, Tamas Zolnai wrote:
> Caolan, I don't see a bug number in the commit message. So I don't
> know what was the actual test case there. Do you remember something
> about what was the issue? Maybe we can find a better solution for
> that.

I've sent Tomas a document which reproduces the original problem.

The document generator is LibreOffice 4.4.5.2, and the document is one
with redlines enabled where there are a massive amount of duplicate
frames anchored to the same paragraph which results in a document which
on load is slow to load and unuseably slow to scroll through or work
with.

I think the source to *that* problem may have been 'Fix single node
CopyRange' 9099e21b89184bd4e39def497e483cac4a77ec5a and that problem
may have been fixed with 'Revert "Fix single node CopyRange"'
e84f0a9b3223f49b0829f2f55dacbf11ae201c1e

If that commit was not the root of the duplicate frames then it was
something of that nature, such that on every save of documents with
frames anchored to certain locations of redlines the frames got
duplicated. So on load the document is impossibly slow to work with.

The catch was what to do about the existing documents containing
duplicate frames generated with versions before the fix went in.

I take your point that "it used to work and now it doesn't" wrt
anonymous/duplicate frame names, but I didn't see any great solutions
to the pressing need to get documents generated by ourselves to load
again and LibreOffice (normally) always writes unique frame and the
spec can be read to indicate that they have to be unique which gave a
way out to repair the existing pool of affected documents by dropping
frames with duplicate names.