Bug 85666 - FORMATTING: Indent increases when alternating between numbering and bullets
Summary: FORMATTING: Indent increases when alternating between numbering and bullets
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.3.2 release
Hardware: Other Linux (All)
: medium minor
Assignee: Caolán McNamara
URL:
Whiteboard: target:4.5.0 target:4.3.7 target:4.4.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2014-10-31 00:15 UTC by srijankedia
Modified: 2016-04-24 16:42 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
more obvious example (11.13 KB, application/vnd.oasis.opendocument.text)
2015-01-15 17:28 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description srijankedia 2014-10-31 00:15:45 UTC
Doing the following sequnce of actions leads to automatically increasing the indent:
1. Create a bullet point (or numbering)
2. Press the "increase indent" button.
3. Switch to numbering (or bullet point). This adds another indent space. Keep alternating between numbering and bullet point, and the indent keeps on increasing.

This does not happen with "decrease indent".

I am using LibreOffice 4.3.3.2 430m0(Build:2) version.
Comment 1 Buovjaga 2014-11-15 13:03:50 UTC
Reproduced.

Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+
Build ID: 5bff4b016c4b44f4123e0e6a4fd4c0c4dc0cfa2d
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-13_00:14:29
Comment 2 Buovjaga 2015-01-09 14:49:47 UTC
Bug not observed in 3.3 or 3.5 -> likely regression.

Ubuntu 14.10 64-bit
LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 3 Dave Richards 2015-01-13 16:57:28 UTC
 84b7f2bee1466b2b42cb32254abdf132dd20ed3c is the first bad commit
commit 84b7f2bee1466b2b42cb32254abdf132dd20ed3c
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Sat May 10 18:48:06 2014 +0000

    source-hash-362c8d67e1cb8920bf179b52c50b5997d32eb296
    
    commit 362c8d67e1cb8920bf179b52c50b5997d32eb296
    Author:     Pavel Janík <paveljanik@apache.org>
    AuthorDate: Tue Nov 26 20:36:34 2013 +0000
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Mon Dec 2 10:27:09 2013 +0000
    
        WaE: compare unsigned values.
    
        (cherry picked from commit e215b94aea58527bf76db44f0985b467502d457b)

:100644 100644 5f1aa382121586f11afa19c011c4cd7426832998 5b641e0949034a17ebe37fcc5721bb8d681f918a M	ccache.log
:100644 100644 86509514b04fc0752ef874d90cb1d49af99be5fd d58a1fda1b6443fe603edcf1a5852106250dbb98 M	commitmsg
:100644 100644 a486bb4138808f28bde440febdff4f6491401607 cd43b5ba40bab2031582507c959155e323fe54a5 M	make.log
:040000 040000 9e1397d961b0dbc4692c41e5d120f26fe681132c 0bd8f3f42aca7a170c71b0cf68638adf30a4cae4 M	opt

git bisect start 'latest' 'oldest'
# good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
# bad: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect bad 4850941efe43ae800be5c76e1102ab80ac2c085d
# skip: [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681
git bisect skip a043626b542eb8314218d7439534dce2fc325304
# skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
# skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
# good: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930
git bisect good c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31
# good: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930
git bisect good c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31
# good: [30cde618212ecaf5725321372bd1b8339f8e2b9f] source-hash-137f872aa8e6e598e7c7ed1ffa4d21e580e22bdb
git bisect good 30cde618212ecaf5725321372bd1b8339f8e2b9f
# good: [30cde618212ecaf5725321372bd1b8339f8e2b9f] source-hash-137f872aa8e6e598e7c7ed1ffa4d21e580e22bdb
git bisect good 30cde618212ecaf5725321372bd1b8339f8e2b9f
# bad: [306d62ec4b911895f08f2bb8efefebed7ac795f0] source-hash-735bd120c9ee2d9bb3514907936c27efb75d7282
git bisect bad 306d62ec4b911895f08f2bb8efefebed7ac795f0
# bad: [306d62ec4b911895f08f2bb8efefebed7ac795f0] source-hash-735bd120c9ee2d9bb3514907936c27efb75d7282
git bisect bad 306d62ec4b911895f08f2bb8efefebed7ac795f0
# bad: [835ce851abe657bb5a8238693ea924287e6890c0] source-hash-1e53784811458563b36fd4cbaa15c2f526a7161b
git bisect bad 835ce851abe657bb5a8238693ea924287e6890c0
# bad: [835ce851abe657bb5a8238693ea924287e6890c0] source-hash-1e53784811458563b36fd4cbaa15c2f526a7161b
git bisect bad 835ce851abe657bb5a8238693ea924287e6890c0
# bad: [159e65f9cccfc8e4774d7a60f00876c07fc7c82a] source-hash-a0be5278c24efcc9a6f22fe5398d780b0744f8ce
git bisect bad 159e65f9cccfc8e4774d7a60f00876c07fc7c82a
# bad: [159e65f9cccfc8e4774d7a60f00876c07fc7c82a] source-hash-a0be5278c24efcc9a6f22fe5398d780b0744f8ce
git bisect bad 159e65f9cccfc8e4774d7a60f00876c07fc7c82a
# bad: [76a4a4db1a4efbead04287a436e59006505bc705] source-hash-5b03bc8a4d92fee2fdfdca4917b321985feb930a
git bisect bad 76a4a4db1a4efbead04287a436e59006505bc705
# bad: [76a4a4db1a4efbead04287a436e59006505bc705] source-hash-5b03bc8a4d92fee2fdfdca4917b321985feb930a
git bisect bad 76a4a4db1a4efbead04287a436e59006505bc705
# bad: [84b7f2bee1466b2b42cb32254abdf132dd20ed3c] source-hash-362c8d67e1cb8920bf179b52c50b5997d32eb296
git bisect bad 84b7f2bee1466b2b42cb32254abdf132dd20ed3c
Comment 4 Matthew Francis 2015-01-14 03:37:48 UTC
The behaviour changed as of the below commit.

Adding Cc: to caolanm@redhat.com; Could you possibly take a look at this one? Thanks


commit 76c549eb01dcb7b5bf28a271ce00e386f3d388ba
Author:     Steve Yin <steve_y@apache.org>
AuthorDate: Fri Nov 29 13:03:27 2013 +0000
Commit:     Caolán McNamara <caolanm@redhat.com>
CommitDate: Mon Dec 2 10:25:33 2013 +0000

    Integrate branch of IAccessible2
    
    Conflicts:
        everything
    
    Change-Id: I9619634ee1e60d449025c006803da29c1e9d14b3
Comment 5 Caolán McNamara 2015-01-15 12:31:41 UTC
That commit basically wired increase indent to do the same thing as "tab" does when the paragraph is bulleted, i.e. increase/decrease the list level.

And the behaviour on toggling bullets to numbers on > level 1 list entries is the same before/after that change.
Comment 6 Caolán McNamara 2015-01-15 17:28:13 UTC
Created attachment 112311 [details]
more obvious example
Comment 7 Caolán McNamara 2015-01-15 17:29:44 UTC
So lets fix the root problem which is that on toggling bullets <-> numbers we do try and match the existing indent but always compare against the first level of the list not the current list. So the further down the list you go the bigger the discrepancy so toggling a number 10 level makes it jump 3/4 way across the page.
Comment 8 Commit Notification 2015-01-15 17:31:09 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=30033deace805ce507c8532c51c42b9ede98db06

Resolves: fdo#85666 when matching existing list indent use matching level

It will be available in 4.5.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 9 Luke 2015-01-15 18:43:41 UTC
I've experienced this annoying glitch. Thanks srijankedia, Dave, Matthew, and Caolán for tracking it down and fixing it. Great job team!
Comment 10 Commit Notification 2015-01-27 15:27:32 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=13386917bf05b515142049595b6b93fae01d2051&h=libreoffice-4-3

Resolves: fdo#85666 when matching existing list indent use matching level

It will be available in 4.3.7.

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 11 Commit Notification 2015-01-27 15:27:45 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5a6a1ccfaa65385d1577c69288a92c3d2571f46&h=libreoffice-4-4

Resolves: fdo#85666 when matching existing list indent use matching level

It will be available in 4.4.1.

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 12 Robinson Tryon (qubit) 2015-12-17 08:38:22 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]
Comment 13 Jean-Baptiste Faure 2016-04-24 16:42:03 UTC
Version set from description.

Best regards. JBF