Description: When working with Track changes in Word, it is important that the tracked changes in the document and the entries in the "Manage Changes" window are related. When you have selected/highlighted a change in the "Manage Changes" window and you make a change (in track changes mode) in the document, the highlight in the "Manage Changes" gets lost and it suddenly jumps to the top of the list. This is unexpected behavior and IMHO incorrect. This bug causes big headaches when working in long documents with many changes! This bug is related to enhancement request bug 161717 which is fixed now, but I was asked to open this as a new separate bug. Steps to Reproduce: 1.Open attached test file 2.Open "Edit" -> "Track changes" -> "Manage Change" 3.Scroll down to the last change and click on it. You now see the change "Fourtieth change" 4. Please correct now the typo that you see in paragraph 40. just above. Actual Results: Result: You see that the selected entry in the "Manage Changes" suddenly gets lost and it unexpectedly jumps to the top of the list. Expected Results: Expected result: It would be better if the previous highlight/selection in the "Manage Changes" window remains. Reproducible: Always User Profile Reset: No Additional Info: Jim Raykowski did some testing on this issue (in bug 161717) and he found out: I repro this only when using gtk3 VCL plugin. Using x11, windows, or qt5 plugins behave for me as you expect. Thus, it may be a gtk3-only bug or a gtk3 regression. System: Version: 7.5.9.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: de-DE (fr_FR.UTF-8); UI: de-DE Ubuntu package version: 4:7.5.9-0ubuntu0.23.04.1 Calc: threaded
Created attachment 195268 [details] Example Writer document for testing focus loss in "Manage Changes" window
I confirm the loss of selection and jump to the first entry in the changes list only when using gtk3 VCL plugin.
For this case: * gtk3 always clears selections and sets the visible range at the start of the list. * qt5/x11/win keep the start of the visible range the same as it was before the change to the document and also keep selections. After looking at this closer I think there is no bug or regression, just a difference in the way these VCL plugins behave when adding items to a list. Making gtk behave like qt/x11/win in this case seems valid to me. But perhaps a case could be made for the opposite, make qt/x11/win plugins behave as gtk, which, after poking at making gtk behave like qt/x11/win, appears to me to be a much easier hack. My experience using the Manage Changes feature is limited to recent enhancement doings so my vote is with those who actually use the feature. Maybe in the future one of those "Ah ha!" moments will happen for me. Maybe someone interested in making this request happen will take it on :) The area of the code I've been poking around to do is: sw/source/uibase/misc/redlndlg.cxx void SwRedlineAcceptDlg::Activate()
(In reply to Jim Raykowski from comment #3) > For this case: [...9 > Making gtk behave like qt/x11/win in this case seems valid to me. But > perhaps a case could be made for the opposite, make qt/x11/win plugins > behave as gtk, which, after poking at making gtk behave like qt/x11/win, > appears to me to be a much easier hack. > > My experience using the Manage Changes feature is limited to recent > enhancement doings so my vote is with those who actually use the feature. [...] Thank you Jim for looking into the causes of this bug (or different behavior of GTK3). I am regularly using the "Manage Changes" feature and I can elaborate a bit what would be the expected behavior (spoiler: it should be like qt/x11/win): Use case (my standard use case using "Manage Changes"): * When I review a long document that contains many changes, I usually open the "Manage Changes" window and go through the changes one by one as they appear in the list. I may accept, reject or alter/edit the change. When accepting or rejecting, the 'bug' is not relevant, because it works as expected. However, when altering/editing the change (or maybe correcting a typo somewhere in the text), I expect to exactly continue there in the list of changes where I was before. However, the 'bug' causes a jump to the top of the list which doesn't make sense at all. The jump absolutely destroys the work flow, because I have to search again the place in the list where I wanted to continue. --> The GTK3 VCL version should keep the selection like qt/x11/win. Use case 2
Created attachment 195296 [details] demo of patch to make selected entry stay selected after edit is made Ah ha! Still get visible range movement but at least the selected entry remains selected and is in the visible range.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d16ac2a8ed46bdc0f20d49850b9c4989697acd49 Resolves tdf#162018 Unexpected loss in focus in the "Manage Changes" It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #6) > Jim Raykowski committed a patch related to this issue. > It has been pushed to "master": Hi Jim, thank you very much. I have tested the fix and it mostly works. I also get visible range movement, but the selected entry remains selected. However, I found two situations, where it does not work as expected: Situation 1: If you select the last entry in the list of "Manage Changes" and you enter some text in the line(s) below that last change in the document. It still jumps to the top of the list. The fix only does not work for anything changed after/below the actual *last* change in the document. Situation 2: If you select any change in the list of "Manage Changes" and you perform a right mouse click on the selected change and click on "edit comment". After having edited the comment, it still jumps to the top of the list.
Here is a link to a patch that addresses the two situations given where the list still jumps to the top: https://gerrit.libreoffice.org/c/core/+/170598
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/de9a7a593630d3319e0e311b641c7c52c96b9e4a Resolves tdf#162018 Unexpected loss in focus in the "Manage Changes" It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #9) > Jim Raykowski committed a patch related to this issue. Hi Jim, thank you so much for the fix. I tested both reported "situations" and they are working fine now. However, unfortunately, I discovered another situation where it suddenly jumps to the top of the list: If you make a change before the first change-tracked change. Description of the case: 1. Select any change in the list of the "Manage Changes" window 2. Make a change before the first change of the document (it doesn't matter if it is in a line before the first change or within the line of the first change. You just have to make an edit before the first change) 3. It suddenly jumps to the top of the list and looses focus/selection. Tested with 21 july 2024 build: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8705cfecd5a10f817d3a2a02041d85e77282aa30 CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
(In reply to Gerry from comment #10) > (In reply to Commit Notification from comment #9) > > Jim Raykowski committed a patch related to this issue. In the LibreOffice daily build of July 23, situation 3 (change before the first change-tracked change) does not work. I assume that your yesterday's fix has not yet been pushed to the master, has it? The page here is down, so I couldn't verify: https://cgit.freedesktop.org/libreoffice/core/log Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a7de9cc5e89cd0d0c2f6363b2c0cc265c528b121 CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/863b90e33c4b9964a697684887aeb42cc538b019 Resolves tdf#162018 Unexpected loss in focus in the "Manage Changes" It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #12) > Jim Raykowski committed a patch related to this issue. > It has been pushed to "master": Thanks a lot Jim. I tested today's daily build and situations 1, 2, 3 work perfectly. I did some more testing with the sample file and I noticed a situation 4 where it again suddenly jumps to the top and loses focus: If the new change makes a change to an entire previous change or to multiple previously tracked changes. Description of situation 4: * Open the example file and select any change, e.g. the last one. * Then just delete three lines, e.g. line "37." to line "39." (this action includes an entire previously change-tracked change, which is entirely changed/deleted by this action) * It suddenly loses focus and jumps to the top. The same issue arises if I make a change that includes several previously change-tracked changes. The issue arises in any action (deleting, overwriting, moving) Tested with LibreOffice daily build from 24 july 2024: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 57f46e0244bdc1165ebbc5e09e4069cc075ff7ae CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c60dd66d89dab2174aa71c26c653f68908c7ba78 tdf#162018 Unexpected loss in focus in the "Manage Changes" window It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #14) > Jim Raykowski committed a patch related to this issue. > It has been pushed to "master": Thanks Jim, I tested today's daily build which contains your yesterday's patch. I tested the original bug description, situation 1, 2, 3, 4 and it works as expected, no jumps. Everything works fine. Thank you so much! LibreOffice daily build 25 july 2024: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c60dd66d89dab2174aa71c26c653f68908c7ba78 CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
@Gerry Super! I'll mark this as RESOLVED FIXED. Let me know if any other issue should arise.