Bug 102315 - EDITING: Increase/Decrease Font Size do not work reliable in Table selections
Summary: EDITING: Increase/Decrease Font Size do not work reliable in Table selections
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium minor
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Writer-Tables-Select Font-Size
  Show dependency treegraph
Reported: 2016-09-20 20:26 UTC by aslmx
Modified: 2019-08-15 00:02 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

Increase/decrease font size in a table (impress) (687.62 KB, video/x-msvideo)
2016-09-22 20:33 UTC, roumanet
Reproduction on LO Writer (1.12 MB, video/mp4)
2018-09-20 18:12 UTC, aslmx
Fixed in LO Writer 6.3 (linux, appimage) (1.20 MB, application/octet-stream)
2019-08-14 21:10 UTC, aslmx

Note You need to log in before you can comment on or make changes to this bug.
Description aslmx 2016-09-20 20:26:39 UTC
The Increase / Decrease Font size tools do not work reliable on the first click if used on a selected Row in a Table within Writer. The font is only increased for a specific Cell on the first Use of the tool. When using for the second and third time etc, all selected Cells text font size will be increased. Still the different Cells have different Font size!

I reproduced this on LO-Writer Version: Build ID: 1:5.0.3~rc2-0ubuntu1~trusty2
Locale: de-DE (en_GB.UTF-8)

As well as with the latest downloadable portable version for Windows Version

The behaviour seems to me as 100% consistently reproducible if you always follow the same steps.

Usecase: you want to make the text in the second row smaller than in the first 
row quickly.

There is a difference in behavior, which seems to depend on the way you select the Cells of a row. I will describe them both

Steps to Reproduce: 
1. Have an empty Document
2. Add a Table by using the toolbar button. Make the table at least 3 Rows and 3 Columns
3. Add any text to every Column


Now Select the second row, by clicking and holding the FIRST Cell in the second row and dragging your Mouse to the RIGHT.


Now Select the second row, by clicking and holding the LAST Cell in the second row and dragging your Mouse to the LEFT.

5. Use The Font Increase or Decrease Tool
6. Make sure selection is not changed. Use the Font Increase or Decrease Tool (but make sure you use the same again as in Step 5!)
7. Check result

Expected Results:
1. Document is Empty
2. An empty Table is created with 3 rows and 3 columns
3. Text can be added to every cell

4. The Row can be selected either way as described in A or B

5. Depending on which tool you used, each Text in Each column of Row 2 is increased or decreased.
6. Again, each text in each column of Row 2 is increased or decreased

Actual Result:
Step 1 to 4 => Fine everything works as expected


If Selection was made using Step 4-A only the Text of the First Cell, i.e. the left most column in Row 2 is increased or decreased

If the selection was made using Step 4-B - and now ladies and gentlemen it gets tricky - only the Text in the second Cell from the right corner is increased.

If the Table is 3x3, it will be the Cell in the middle (Row 2, Column 2). 
If the Table is 3 Rows, 4 Columns (3x4), it will be the Cell in Row 2, Column 3 If the Table is 3 Rows, 5 Columns (3x5), it will be the Cell in Row 2, Column 4

6. All selected text is increased or decreased, works fine, if you just analyse this step as a single step without the steps before.

While i started playing around, i found even more possibilities of this Tool not working when rows or part of Tables are selected in different ways.

Multi Rows:
When you have 4 Rows and select the two middle rows (i.e. 2 and 3). It not only depends in which direction (left / right) you select the columns, but also which row you select first.

It also makes a difference if you first select the first column of row 3, go up one cell and then go right to select the full two rows. I'm not writing a lengthy description of all possibilities...

Multiple Cell text select:
If you select lets say the text of 2 different cells by using the CTRL key and selecting the text (not the actual cell), the first use of the increase/decrease tool does not work at all. The second use then changes both cells properly.

What matters is: not all cells are updated - but interestingly this works on the Second Use of the tool, but still, the cell that was the only cell being updated in the first step needs to be changed again because it is increased/decreased one step to much.
Comment 1 roumanet 2016-09-22 20:33:06 UTC
Created attachment 127561 [details]
Increase/decrease font size in a table (impress)

Work Around : first time there is the bug, next clics are OK... at th end, select first cell and decrease one time.
Comment 2 Buovjaga 2016-10-11 18:09:07 UTC
I confirm the result (only first cell or only second-from-right), but only with the first click of Increase/Decrease. Howver, then the damage has been done: the others start to change, but the first changed one remains out of synch.
If you hover your mouse to the left side of the row so it turns into an arrow ("Select table row") and click to select, the selection is treated like step 4-A.

Note for testers: View - Toolbars - Text object

Good news for bug fixing, though: this is a regression, not happening in 3.6.

Arch Linux 64-bit, KDE Plasma 5
Build ID: 65f2d6b1cc40b4b90f8987e8ea14d24b5f38f950
CPU Threads: 8; OS Version: Linux 4.7; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on October 10th 2016

Arch Linux 64-bit
Version (Build ID: e183d5b)
Comment 3 raal 2016-10-25 05:34:48 UTC
This seems to have begun at the below commit.
Adding Cc: to Noel Grandin; Could you possibly take a look at this one? Thanks
 a76d0f97956bfb5f9fed24d0152df27c7bfcba6c is the first bad commit
commit a76d0f97956bfb5f9fed24d0152df27c7bfcba6c
Author: buildslave <buildslave@tb51.libreoffice.org>
Date:   Tue Apr 12 17:30:42 2016 +0200


    commit 78b0b292637ebdeb2e4a7f08e0e8128530caaa18
    Author:     Noel Grandin <noel@peralex.com>
    AuthorDate: Mon Nov 3 15:00:58 2014 +0200
    Commit:     Noel Grandin <noel@peralex.com>
    CommitDate: Mon Nov 3 15:04:52 2014 +0200

        svgio: two of the token names were not being mapped to tokens

        Change-Id: I2be280ff8ebbf1046047a5bb4463191462172e24
Comment 4 Noel Grandin 2016-10-25 07:22:46 UTC
Sorry, raal, but reverting that commit does not fix the problem. Are you sure about the result of the bibisect? It normally returns a range of commits, not a single commit.
Comment 5 raal 2016-10-27 18:16:34 UTC
Did the bibisect again:

git bisect log
# bad: [489ffd1df414698b6cea9ab03bf6f663b8b5af7e] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2
# good: [8aa9fc9a0c92172593d6cd97662116a965db229d] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474
git bisect start 'latest' 'oldest'
# good: [897913acd244cb6a5d2f4c2da1d625d9b978edb6] source-hash-ac57362b23859591c088e36b7218f4a606dcf3bb
git bisect good 897913acd244cb6a5d2f4c2da1d625d9b978edb6
# good: [860f6172be84c3d801e1e533ab3d12a28815cb4c] source-hash-80c11d648e88f3195f7e4fb465cd6902bcf46867
git bisect good 860f6172be84c3d801e1e533ab3d12a28815cb4c
# good: [fe0abc50dc1e45fd73635394f8df41e0dfc3eec8] source-hash-4e223fab04279c3583689e69fa1342966e81de36
git bisect good fe0abc50dc1e45fd73635394f8df41e0dfc3eec8
# bad: [247d0249eb9794ccedec0ca2e3309b8d970593cc] source-hash-1535f39388223de53e4b923c6f7bb71ee32c1858
git bisect bad 247d0249eb9794ccedec0ca2e3309b8d970593cc
# bad: [6cf25fb7af89cc58453d4bda5135e05ca220b1a4] source-hash-ddd549c7873404d0c09aca676a13660404b0bcd2
git bisect bad 6cf25fb7af89cc58453d4bda5135e05ca220b1a4
# good: [4bc4b71d33640cd55abb1be0893e86512c5ab0c3] source-hash-78e670b3055f92740402803174d61d058effb5d7
git bisect good 4bc4b71d33640cd55abb1be0893e86512c5ab0c3
# bad: [88e99ac6c8e25a75799fdb2f9258845d49642b8e] source-hash-bce4f8dd83143c74c52d2fbb4527ba8a1ff71ed3
git bisect bad 88e99ac6c8e25a75799fdb2f9258845d49642b8e
# good: [771ed7a9553d622425ab44af64cf793732e3f173] source-hash-eb8530cc90ff12fa79ac24fd9703422a7e8c8415
git bisect good 771ed7a9553d622425ab44af64cf793732e3f173
# bad: [81c6d9efac3cac4287ef98802a672caf0325ca37] source-hash-cc1a4d72ebed4169a057ca02c5dd05d986c35cce
git bisect bad 81c6d9efac3cac4287ef98802a672caf0325ca37
# bad: [a76d0f97956bfb5f9fed24d0152df27c7bfcba6c] source-hash-78b0b292637ebdeb2e4a7f08e0e8128530caaa18
git bisect bad a76d0f97956bfb5f9fed24d0152df27c7bfcba6c
# first bad commit: [a76d0f97956bfb5f9fed24d0152df27c7bfcba6c] source-hash-78b0b292637ebdeb2e4a7f08e0e8128530caaa18

these commits
2014-11-03    svgio: two of the token names were not being mapped to tokens    Noel Grandin    1    -0/+2
2014-11-03    fdo#39468 Translate German Comments - final bits of sc/source/filter/    Christian M. Heller    3    -10/+10
2014-11-03    fdo#84795 Menu, DropDown-List don't disappear with right mouse click    Juergen Funk    3    -24/+33
2014-11-03    fdo#35862 De-/Increase font when multi-sized text    Daniel Sikeler    3    -20/+232
2014-11-03    fix memory leak of pointers contained in m_aErrDescList    Takeshi Abe    2    -12/+8
2014-11-03    sw doc model xml dump: handle RES_FRMATR*STYLE_NAME    Miklos Vajna    1    -0/+16
2014-11-03    fdo#61167 suggest titlecase and uppercase words from exception dict    Andras Timar    1    -2/+42
2014-11-03    typo: geomtery -> geometry    Andras Timar    1    -1/+1

Daniel, Samuel,
can it be this one?
author    Daniel Sikeler <d.sikeler94@gmail.com>    2014-09-22 08:26:06 (GMT)
committer    Samuel Mehrbrodt <s.mehrbrodt@gmail.com>    2014-11-03 11:26:21 (GMT)
commit    98c95ce3a759a6f691c20cb1e376fa54a9dfdbc0 (patch)
tree    b78364d64ab90c64fb02623d0738c05bc4e43619
parent    fe1f258d5b77cd6e6a7483d7cf28195dbfdd62a4 (diff)
fdo#35862 De-/Increase font when multi-sized text
Added two new function to the SwEditShell.
The first returns all items of a specific WhichId wich belong to the current selection. The items from the attribute set and from the hints are used.
The second returns SwPaMs separated at borders of an itemtype  identified by its WhichId. The SwPaMs must be deleted after yous.
Comment 6 Aron Budea 2017-01-08 03:56:31 UTC
Adjusting earliest version to
Comment 7 Aron Budea 2017-01-08 08:58:46 UTC
I confirm the bug is caused by the commit suggested by raal in comment 5.
Comment 8 QA Administrators 2018-06-19 02:45:38 UTC Comment hidden (obsolete)
Comment 9 aslmx 2018-09-20 18:11:04 UTC
I just took the time to retest - i'm using LO Writer in the latest version that is available to Linux mint 19 users, which happens to be:

Build ID: 1:6.0.3-0ubuntu1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group

The issue is still reproducible. The Behaviour is not as expected.

In the meanwhile i found a nice tool which does screen capture. So i made a video to easily show you this weird behaviour ;-)

Comment 10 aslmx 2018-09-20 18:12:32 UTC
Created attachment 145075 [details]
Reproduction on LO Writer

Video as promised...
Comment 11 aslmx 2018-09-20 18:22:40 UTC
btw: happy birthday bug! 
Actually this bug is exactly 2 years old today - and it was NOT by intention but pure coincidence that i retested it - really :) - SCNR posting this ;)
Comment 12 aslmx 2019-08-14 21:10:46 UTC
Created attachment 153396 [details]
Fixed in LO Writer 6.3 (linux, appimage)

The bug should be fixed now.
Comment 13 aslmx 2019-08-14 21:12:40 UTC
Almost 3 years after I initially raised this, I could no longer reproduce this with the latest LO Writer, 6.3 on linux via AppImage. 

I consider it fixed.

Thanks a lot!
Comment 14 Aron Budea 2019-08-15 00:02:59 UTC
Thanks for retesting! Let's change status to WORKSFORME, since the fixing commit is unknown.