Bug Hunting Session
Bug 60513 - EDITING: Text selection in the entire table is undone when some format is applied
Summary: EDITING: Text selection in the entire table is undone when some format is app...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: Other All
: high normal
Assignee: Michael Stahl (CIB)
URL: http://ask.libreoffice.org/en/questio...
Whiteboard: BSA bibisected40 target:4.1.0 target:...
Keywords: regression
: 60566 61673 62574 62684 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-02-08 19:57 UTC by Gláucio de Araujo
Modified: 2017-04-19 14:26 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gláucio de Araujo 2013-02-08 19:57:01 UTC
Problem description: When a table is all selected and I try to format something (like paragraph), the selection is undone and the format is only applied to the cell the cursor is.

Steps to reproduce:
1. Create a table with some contents...
2. Select all the table...
3. Go to Format > Paragraph

Current behavior: The selection is undone.

Expected behavior: To keep the selection and apply the format to all cells.

              
Operating System: All
Version: 4.0.0.0.alpha1
Last worked in: 3.6.5.2 release
Comment 1 Gláucio de Araujo 2013-02-08 20:02:47 UTC
The bug was observed in 4.0.0 release, but the bug assistant didn't have this option.
Comment 2 manj_k 2013-02-12 11:29:49 UTC
*** Bug 60566 has been marked as a duplicate of this bug. ***
Comment 3 manj_k 2013-02-12 11:35:08 UTC
Reproducible with LO 4.0.0.3 release (on WinXP).
Also confirmed with bug 60566.
Comment 4 Joel Madero 2013-02-12 20:16:54 UTC
Incorrectly prioritized, changing.

Normal: usually I'd say minor but because it's a regression bumped it up to normal, doesn't prevent high quality work, just makes it harder.

High: regression + common task
Comment 5 Joel Madero 2013-02-12 20:32:14 UTC
18ab426f67674e3ca169118f1f7a3527613374a4 is the first bad commit
commit 18ab426f67674e3ca169118f1f7a3527613374a4
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Mon Dec 10 15:58:33 2012 +0000

    source-hash-4df639baacd871cb2793e75dd9721ad2ae715e20
    
    commit 4df639baacd871cb2793e75dd9721ad2ae715e20
    Author:     Norbert Thiebaud <nthiebaud@gmail.com>
    AuthorDate: Sat Sep 29 02:34:58 2012 -0500
    Commit:     Norbert Thiebaud <nthiebaud@gmail.com>
    CommitDate: Sat Sep 29 02:43:29 2012 -0500
    
        add apache_commons to tail_build
    
        Change-Id: I0365a5170011ad44b9a0ab8f1129a756884694d5

:100644 100644 66afa24b4b34cc1d198b4a9564ede557456555c3 0a27364dbfe85236f5a07a9baeb2ce5dc923140f M	autogen.log
:100644 100644 592002353c9c447688ae5ed55b4ec616e85568a3 59e71ae19992a0d27f4cd5a0660f4d0ae6a6baa9 M	ccache.log
:100644 100644 0b4eee5b69c2cc366273a7e684ebea96d6a49004 5cf4528dc90d7fb24081eba730189499b41b3364 M	commitmsg
:100644 100644 1424b8601b3a84d22208d2ad9fa54bd6aa940713 ae40a46c4d748e32f497c8be5421282bba577ac9 M	dev-install.log
:100644 100644 99903952fe667006084e3f44517e56af706a6fcf 31ff34b5efe337e22e4987f46b328e59bc699817 M	make.log
:040000 040000 1b572f2dde3a8e76bcad94e0fba6e0632bfcab87 b9e6f554ff60c2a6fdbdc177bcc35d9d7160a9b5 M	opt



# bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c
git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9
# good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda
git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a
# bad: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902
git bisect bad 114fd3b76bcba890e6d702d00cef910f1493c262
# good: [6af64581913aa7ce3fcf0890fe671830d416a6ea] source-hash-06a8ca9339f02fccf6961c0de77c49673823b35f
git bisect good 6af64581913aa7ce3fcf0890fe671830d416a6ea
# bad: [7e20e241c1d8819d8d5edb7894baeddde33f9d3a] source-hash-2c270eeff422ef93100376ce0717a131d4f3cc2f
git bisect bad 7e20e241c1d8819d8d5edb7894baeddde33f9d3a
# bad: [18ab426f67674e3ca169118f1f7a3527613374a4] source-hash-4df639baacd871cb2793e75dd9721ad2ae715e20
git bisect bad 18ab426f67674e3ca169118f1f7a3527613374a4
# good: [8004efc7f77e76e1dc66eeb0fa7f2b9b2cf9cc05] source-hash-9351d0e4181924c3f72be24081fc7af027aa41f7
git bisect good 8004efc7f77e76e1dc66eeb0fa7f2b9b2cf9cc05
# good: [5132488fc8156d7eec31097f0e8036dbb6612b10] source-hash-fba5febdf60b37be69d2ffc66445d3e324826346
git bisect good 5132488fc8156d7eec31097f0e8036dbb6612b10
Comment 6 manj_k 2013-03-02 21:43:58 UTC
*** Bug 61673 has been marked as a duplicate of this bug. ***
Comment 7 manj_k 2013-03-20 22:35:40 UTC
*** Bug 62574 has been marked as a duplicate of this bug. ***
Comment 8 Michael Stahl (CIB) 2013-03-27 11:58:33 UTC
hmm... this is caused by this commit:

commit 004369c76a3c43a478d668521bf7cee3176bf5d7
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Tue Feb 7 09:20:47 2012 +0000

    force all tabs to exist when layout enabled

... which is not really introducing the bug;
the bug has existed back to OOo 3.0.1:

select the cells, open Format->Paragraph,
now click the "Drop Caps" tab page and the selection is cancelled.

the commit above simply activates all tab pages once,
including the buggy "Drop Caps" one, making the bug more visible.
Comment 9 Gláucio de Araujo 2013-03-27 12:15:17 UTC
True... I see that in 3.6. The user has any way to change this default behavior in 4.x? 




(In reply to comment #8)
> hmm... this is caused by this commit:
> 
> commit 004369c76a3c43a478d668521bf7cee3176bf5d7
> Author: Caolán McNamara <caolanm@redhat.com>
> Date:   Tue Feb 7 09:20:47 2012 +0000
> 
>     force all tabs to exist when layout enabled
> 
> ... which is not really introducing the bug;
> the bug has existed back to OOo 3.0.1:
> 
> select the cells, open Format->Paragraph,
> now click the "Drop Caps" tab page and the selection is cancelled.
> 
> the commit above simply activates all tab pages once,
> including the buggy "Drop Caps" one, making the bug more visible.
Comment 10 Michael Stahl (CIB) 2013-03-27 22:49:07 UTC
so the problem is the code in SwDropCapsPict::UpdatePaintSettings()
which does:

            pPage->rSh.Push();
            pPage->rSh.ClearMark();
            ...
            pPage->rSh.Pop(sal_False);

the Push will store the pCurCrsr of the SwCrsrShell, which
in the case of a table selection is just one of the selected cells
(the rest of the cursor ring containing the other cells is not stored).

unfortunately ClearMark() will clear not just the pCurCrsr but
also the table cursor which is stored separately in SwCrsrShell
because life wouldn't be as much fun otherwise.

after thinking for some hours how the separate table cursor
could be stored (which appears to be quite difficult, think
of scenarios like Push, ClearMark, Push again, now you have
2 pCurCrsr to restore but just 1 table cursor, and how to
do that if the darn things are Rings...) i tried just
storing the position of the table cursor in Push()
and strangely this actually seems to work, because
UpdateCrsr() etc. will actually restore the table cursor
and the full cell cursor ring from a pCurCrsr that spans
multiple cells.  the fact that this seems to work is of
course highly suspicious :)
Comment 11 Commit Notification 2013-03-27 22:52:56 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

fdo#60513: SwCrsrShell::Push(): take position from table cursor



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 Commit Notification 2013-03-28 08:30:19 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

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

fdo#60513: SwCrsrShell::Push(): take position from table cursor


It will be available in LibreOffice 4.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 13 Michael Stahl (CIB) 2013-04-24 20:40:12 UTC
*** Bug 62684 has been marked as a duplicate of this bug. ***
Comment 14 Robinson Tryon (qubit) 2015-12-22 01:31:19 UTC Comment hidden (obsolete)