Bug 94063 - EDITING References break when putting text behind them.
Summary: EDITING References break when putting text behind them.
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: highest critical
Assignee: Not Assigned
Keywords: bibisected, haveBacktrace, regression
Depends on:
Reported: 2015-09-09 15:39 UTC by Malte
Modified: 2016-03-29 15:32 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:

example document for reference breakage (13.70 KB, application/vnd.oasis.opendocument.text)
2015-09-09 15:39 UTC, Malte

Note You need to log in before you can comment on or make changes to this bug.
Description Malte 2015-09-09 15:39:05 UTC
Created attachment 118551 [details]
example document for reference breakage

References break when you do so much as put a space behind them.


Open attached document.
Move the cursor behind one of the 2 references in the table under Headline 3.
Hit the space bar.


Mark one of the cells with a reference.
Cut the cell.
Paste the cell somewhere else.

Comment 1 Buovjaga 2015-09-18 10:07:41 UTC
Put a space behind 2 and 2.1 turned into: Error: Reference source not found

Win 7 Pro 64-bit, Version: (32-bit)
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: fi-FI (fi_FI)
Comment 2 Cor Nouws 2015-10-06 12:32:22 UTC
Indeed WTF..
Comment 3 Terrence Enger 2015-10-08 20:18:35 UTC
I see the problem a bit differently: the reference in row 7 col 3 is
already broken in the attachment.  Certain user actions cause the displayed
text of that reference to be updated.  It may or may not be
coincidental that officeotron reports 24 errors in the file.

Working in the daily dbgutil bibisect repository, I used the following

( 1) Load att't.

( 2) Type "<Ctrl>+<End>" three times.  The caret goes to the end of
     the document.  Row 7 of the table is visible.

( 3) <Ctrl>+<click> on the reference in row 7 column 3.  Observe that
     the caret moves just before the reference in question.

( 4) For the reference in row 7 column 3, change Selection to "2.1
     Subheading asdf".  (right-click > Fields...; in pane Selection
     click "2.1 Subheading asdf".)

( 5) <ctrl>+<Click> on that reference.  Observe that the caret moves:
     "2.1 ^Subheading asdf".

( 6) File > "Save As..." and save under a new name.

( 7) File > Close

( 8) In Start Center, File > "Recent Documents" > 1

( 9) Type "<Ctrl>+<End>" 3 times.  Row 7 of the table is visible.

(10) <ctrl>+<Click> on the reference in row 7 column 2.
      - condition good : Observe the caret moves "2.1 ^Subheading asdf".
      - condition bad  : caret moves before the reference.

From `git bisect bad` I get...

    7a286d694a0fc1faa6daf6eac93bcf4a59eebe08 is the first bad commit
    commit 7a286d694a0fc1faa6daf6eac93bcf4a59eebe08
    Author: Miklos Vajna <vmiklos@collabora.co.uk>
    Date:   Thu May 21 05:48:32 2015 +0200

        2015-05-21: source-hash-1c9302565aefb5a54b1b7f1478dd6dac724d30ea

    :100644 100644 7acbb8c8b137cefa170d59c44b2258d3940e13e0 8c3c925d6300868ebc99b4e20b2ab00174080190 M	build-info.txt
    :040000 040000 ef4b5928e9091b35b0865516e8759b757a751b46 7edd2a573ba319f3da3ec5746bab57308ce6eebe M	opt

and from `git bisect log` ...

    # bad: [2ad98b12d82c4ada5756881f0d6074154976e95c] 2015-10-08: source-hash-2e6feddc53830406fa04b4a0aea49bb8438dc702
    # good: [2b392af9c8f54629e3a3a98a8c92fa5af1c6722f] 2015-05-20: source-hash-90e2dabb8d0bb5382234be776c2ad0e2d5d9e224
    git bisect start '2ad98b12d82c4ada5756881f0d6074154976e95c' '2b392af9c8f54629e3a3a98a8c92fa5af1c6722f'
    # bad: [7b4308803bb448efe4d64dcdea03e9d5be6dde9d] 2015-07-29: source-hash-62e2fae93e8894f73560a30ae1e752cbd4c001ad
    git bisect bad 7b4308803bb448efe4d64dcdea03e9d5be6dde9d
    # bad: [57aaa0c171166a76dcd09e7092f5ae111d4b5ccb] 2015-06-24: source-hash-2135fe0cef7bcf7160719f1f29ad65f2b064984b
    git bisect bad 57aaa0c171166a76dcd09e7092f5ae111d4b5ccb
    # bad: [2ff6fad6384c0192ea61bd9a163c8df3818ba8b3] 2015-06-06: source-hash-587006cac508616f486aea45e265a170bcccdc87
    git bisect bad 2ff6fad6384c0192ea61bd9a163c8df3818ba8b3
    # bad: [7b138bcf32b52eccf484bd66d9ab5c70a7970805] 2015-05-28: source-hash-be01d68420086fc36ecf26b5f597ba7c6b29b369
    git bisect bad 7b138bcf32b52eccf484bd66d9ab5c70a7970805
    # bad: [f39c4096f247626f7447321154de73b0c0dbc6b7] 2015-05-24: source-hash-891304bb0ad3af9d8d73f947f25477abf57485a4
    git bisect bad f39c4096f247626f7447321154de73b0c0dbc6b7
    # bad: [33e7c549fd7aa03e831a939201aa06dd80edb2b0] 2015-05-22: source-hash-edcd1d5a9c88455fd1d52ab25815fc8d439f31ec
    git bisect bad 33e7c549fd7aa03e831a939201aa06dd80edb2b0
    # bad: [7a286d694a0fc1faa6daf6eac93bcf4a59eebe08] 2015-05-21: source-hash-1c9302565aefb5a54b1b7f1478dd6dac724d30ea
    git bisect bad 7a286d694a0fc1faa6daf6eac93bcf4a59eebe08
    # first bad commit: [7a286d694a0fc1faa6daf6eac93bcf4a59eebe08] 2015-05-21: source-hash-1c9302565aefb5a54b1b7f1478dd6dac724d30ea

I am removing whiteboard bibisectRequest and setting keyword bisected.
Comment 4 Terrence Enger 2015-10-08 20:36:03 UTC
Silly me.  The daily dbgutil bibisect repository is not "dense".  I am
removing keyword bisected and adding whiteboard bibisected.
Comment 5 Cor Nouws 2015-11-02 15:23:37 UTC
AFAICS the fix for bug 94804 (to test in also fixes this one.
Setting whiteboard target accordingly
Comment 6 Terrence Enger 2015-11-19 23:42:28 UTC
In comment 3, step (10), I meant row 7 column 3, of course.

That said, I see the old behavior in daily dbgutil bibisect version
2015-11-18.  I am setting bug status NEW.
Comment 7 Robinson Tryon (qubit) 2015-12-14 05:17:16 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
Comment 8 Björn Michaelsen 2016-03-28 16:28:17 UTC
(clearing whiteboard as per comment 6)
Comment 9 Cor Nouws 2016-03-29 07:11:05 UTC
This just works fine in on Ubuntu 32 bits.
IMO a WorksForMe as explained in comment #5

@Terrence Enger / @Malte
Can you check please?
Comment 10 Terrence Enger 2016-03-29 15:32:33 UTC
This works well for me in daily Linux dbgutil bibisect version 2016-03-29.

I am setting RESOLVED WORKSFORME.  Malte, if you disagree, please set the bug back to UNCONFIRMED.