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: 5.0.3.2 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 5.2.1.2 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 4-A: Now Select the second row, by clicking and holding the FIRST Cell in the second row and dragging your Mouse to the RIGHT. 4-B: 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 5. 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.
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.
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 Version: 5.3.0.0.alpha0+ 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 3.6.7.2 (Build ID: e183d5b)
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 source-hash-78b0b292637ebdeb2e4a7f08e0e8128530caaa18 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
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.
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 http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=eb8530cc90ff12fa79ac24fd9703422a7e8c8415..78b0b292637ebdeb2e4a7f08e0e8128530caaa18 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.
Adjusting earliest version to 4.4.0.3.
I confirm the bug is caused by the commit suggested by raal in comment 5.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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: Version: 6.0.3.2 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 ;-) Enjoy!
Created attachment 145075 [details] Reproduction on LO Writer 6.0.3.2 Video as promised...
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 ;)
Created attachment 153396 [details] Fixed in LO Writer 6.3 (linux, appimage) The bug should be fixed now.
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!
Thanks for retesting! Let's change status to WORKSFORME, since the fixing commit is unknown.