Bug 86397 - Bookmark: no consecutive name numbering applied when copied
Summary: Bookmark: no consecutive name numbering applied when copied
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha2
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:5.1.0 target:5.0.3
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2014-11-17 14:38 UTC by sophie
Modified: 2016-10-25 19:20 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot of the navigator (165.85 KB, image/png)
2014-11-17 14:38 UTC, sophie
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sophie 2014-11-17 14:38:33 UTC
Created attachment 109624 [details]
screenshot of the navigator

Hi, In the Navigator a wrong numbering is applied when the text containing bookmarks is copied, see the screenshot, it should be numbered 1 instead of 4 and 5. The listing also is still wrong while correctly displayed in the Status bar (right click on the page number).
Version: 4.4.0.0.alpha2+
Build ID: 50ab596fa526244dbb3115029a5e87464b939305
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-11-17_01:42:28
Locale: fr_FR
The numbering (1) is correctly added and listing is correct in:
Version: 4.3.2.1
Build ID: f9b3ad49d92181b0a1fe7e76f785a2c2cd0847d3
Sophie
Comment 1 Jacques Guilleron 2014-11-20 13:13:23 UTC
Hello Sophie,

I reproduce with:
LO 4.4.0.0.alpha2+ Build ID: 4f18bd405831c31cd49190046f7bafd805a47d7d
TinderBox: Win-x86@39, Branch:master, Time: 2014-11-20_09:39:04
Locale: fr_FR
& Windows 7 Home Premium
Last working version for me:
4.4.0.0.alpha1+ Build ID: a8c24b25fd9fb21097a08a22797bf61b59099ea1
TinderBox: Win-x86@39, Branch:master, Time: 2014-10-21_06:33:33

I set Status to NEW.

Have a nice day,

Jacques
Comment 2 Björn Michaelsen 2014-11-21 10:47:09 UTC
There is no promise that LibreOffice will name the copied bookmark in a specific way based on the old name. The important part is that it is not named in the same way as an existing bookmark in the document. Thus marking this an enhancement.

Making a promise that a copied bookmark would be named "foo 1", "foo 2", etc. would mean to need to check on every insertion. This is prohibitive for e.g. a document with lots of bookmarks used in a big mail-merge (as the bookmarks are getting copied again and again). Anyone trying to provide a fix for this should be aware of that and be careful not to break mail-merge performance.
Comment 3 Cor Nouws 2015-03-26 13:29:02 UTC
Hi Bjoern, Sophie,

"there is no promise" except that it worked like that for more then a decade.
Now I have a automated solution for a small customer (that cannot afford support contracts, apart from paying most of time I spent there what allows me to do some voluntary work here) ...

  (also see https://bugs.documentfoundation.org/show_bug.cgi?id=86395#c7

Copied bookmarks were nicely named in previous versions
 Previous: Copy A and B >> A1, B1, A2, B2
 Currently: Copy A and B >> A5, B6, A7, B8
which makes searching in many copied bookmarks (post merge handling of serial letters...) a night mare, if not impossible.
(Also see https://bugs.documentfoundation.org/attachment.cgi?id=114372 from issue fdo#86395)

I would be surprised if I'm the only one that runs into this.
The whole bookmark handling has been changed. For a good reason (at least partly, as far as I can judge), namely to help improving speed for mail merge with large datasets.

I've no idea if the naming can be corrected again without sacrificing speed to much (but honestly I'm not optimistic).
Comment 4 Matthew Francis 2015-03-26 14:00:34 UTC
This appears to have begun at the below commit. Bug 89214 is also related to this commit, but with a completely different symptom so I will leave this as a separate bug.

Adding Cc: to l.lunak@collabora.com; Could you possibly take a look at this? Thanks


    commit bb00a0097900ae054401f7758a915047cfde4065
    Author:     Luboš Luňák <l.lunak@collabora.com>
    AuthorDate: Sat Nov 8 09:41:02 2014 +0100
    Commit:     Luboš Luňák <l.lunak@collabora.com>
    CommitDate: Sun Nov 9 19:45:12 2014 +0100
    
        do not bother with nice unique names during mailmerge
    
        When using a single document for all the generating MM documents, there can
        be a significant number of sections/etc. , enough to make searching them
        all in order to find a next nice unique name take a noticeable time. Since
        it's very unlikely anybody will ever care about nice names after mailmerge,
        just get some unique name in a fast way.
    
        Change-Id: Id6b8d39a67529984cb93bb369f2c6eab401f1799
Comment 5 Björn Michaelsen 2015-07-03 22:44:51 UTC
Making the 'consecutive promise' without breaking mailmerge performance still is an enhancement.
Comment 6 Cor Nouws 2015-09-23 14:09:36 UTC
patch in gerrit https://gerrit.libreoffice.org/#/c/18816/
Comment 7 Commit Notification 2015-09-23 21:56:39 UTC
Cor Nouws committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2fcf8923d2c520a5a16b1b3a45877adaadd7eab4

tdf#86397  Bookmark: no consecutive name numbering applied when copied

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2015-09-24 23:23:56 UTC
Cor Nouws committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a9670e0735b77ecc40aa8af4106af7d32ec548a0&h=libreoffice-5-0

tdf#86397  Bookmark: no consecutive name numbering applied when copied

It will be available in 5.0.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 9 tommy27 2015-10-10 09:58:49 UTC
@Cor
did you forget to set status to FIXED?
I think you deserved to do it yourself...
Comment 10 Cor Nouws 2015-10-10 10:12:24 UTC
OK Tomasso, let me do that. Thanks.
(Thought that it would go automagically..)
Comment 11 Cor Nouws 2015-10-10 10:12:37 UTC
.
Comment 12 Cor Nouws 2015-10-10 10:26:51 UTC
@miklos:
What do you think: could this be safely backported to 4.4.6 or 4.4.7 is we get some heavy mail-merges test with 5.0.3.1 for example ?
thanks - Cor
Comment 13 Robinson Tryon (qubit) 2015-12-17 08:39:29 UTC Comment hidden (obsolete)