tdf#106959: use table's first content node for cursor cleanup

The problem was that when doing the SHELL mail merge with a document
starting with a table, the generated marks point to the first node on
the page, which is not a content node, but a table node. When getting
page numbers for such mark, cursor got cleaned up, meaning that it
looked for a content node as the cursor position. The lookup tried
to go to a previous content node first, and that gave a content node
on the previous page.

The cursor position cleanup was introduced for i#18014 in commit
468c7b8d3287712c6959cd531c71875f4d26bcbc
Author Jens-Heiner Rechtien <hr@openoffice.org>
Date   Fri Jan 04 12:19:29 2008 +0000
INTEGRATION: CWS sw8u10bf02 (1.66.92); FILE MERGED

The bug was incorrect restoration of cursor position after inserting
a row to a table, placing cursor there, and undoing.
I have checked that the mentioned scenario keeps the cursor inside the
table, not jumps to the beginning of the document, as it did before
the mentined commit.

Unfortunately, I don't see how to test this properly in
sw/qa/extras/mailmerge/mailmerge.cxx; FILE mailmerge tests there use
a different code path; and SHELL tests obviously do not perform the
post-processing from SwMMResultSaveDialog::SaveOutputHdl_Impl. Likely,
an UITest would be needed.

But why do we use this SHELL + post-processing here, instead of using
the same FILE mail merge that is performed from form letter dialog,
when SwDBManager::Merge is called from SwDBManager::ExecuteFormLetter
with properly constructed SwMergeDescriptor? That would also speed up
the merge, avoiding extra steps of generating full resulting document
in memory, saving it to a temporary file, just to split it to pieces
(TODO/LATER).

Change-Id: I269de4ae3407261c4f6df51cacd5fc72643fd29a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139973
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

0 files changed, 0 insertions, 0 deletions