Steps to Reproduce: 1. New Writer, type two paragraphs. 2. Apply the 1st paragraph with style "Default Paragraph Style > Heading > Heading 1". Apply the second paragraph with style "Default Paragraph Style > Text Body > First Line Indent". Any other styles are all OK to trigger this bug, provided that the style is in a 3rd level of the tree. 3. Fold the styles by clicking on the arrow besides the "Default Paragraph Style" (i.e. the first level style), then switch between the two paragraphs in the text area. Current Result: When switching between paragraphs, the styles tree does not expand automatically to the current style being used by the active paragraph. Expected Result: When the first paragraph is active, the styles tree should expand and highlight to "Heading 1"; when the second paragraph is active, the style tree should expand and highlight to "First Line Indent". Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 8e8e0aefc998adba749a93cacc4660d859fba675 CPU threads: 8; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: zh-CN (zh_CN.UTF-8); UI: en-US Build Platform: Fedora34@X64, Branch:master, bibisect-linux-64-7.4-CN Calc: threaded Fedora 36, Wayland.
This is a regression. Bibisected and bisected to the following commit: commit 8e8e0aefc998adba749a93cacc4660d859fba675 Author: Jim Raykowski <raykowj@gmail.com> Date: Wed Jun 22 17:53:10 2022 -0800 tdf#149279 SwNavigator enhancement to show at least two headings above tracked heading For gtk3, treeview scroll_to_row to a visible collapsed row makes the row expanded. The sal version does not. To make the behavior consistent, the patch removes the call to gtk_tree_view_expand_to_path which causes a visible collapsed row to expand. This commit was initially in 7.5.0.0.alpha0+ and was further backported to 7.4.0 beta2. Adding Jim Raykowski to cc: would you please take a look? Thank you in advance.
I confirm the regression and am looking into it.
Proposed patch: https://gerrit.libreoffice.org/c/core/+/141048
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/53d5f5e15c005d95fa8c9d24d98e26afd2ca2103 tdf#151387 Fix regression cause by tdf#149279 It will be available in 7.5.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.
Dear Jim Raykowski: Thank you for the quick fix. I do not see any backport patch on gerrit for libreoffice-7-4 branch. Would you also prepare for that?
(In reply to Kevin Suo from comment #5) > Dear Jim Raykowski: Thank you for the quick fix. I do not see any backport > patch on gerrit for libreoffice-7-4 branch. Would you also prepare for that? Unfortunately I received this message when trying to cherry-pick to libreooffice-7-4 branch: Cherry Pick Conflict! Cherry Pick failed! (merge conflicts) Please select "Continue" to continue with conflicts or select "cancel" to close the dialog. I am guessing it is safe to continue with conflicts and then resolve them. Can you advise me?
You should do git cherry-pick and then resolve the conflicts manually. What I will do is: $ git cherry-pick 53d5f5e15c005d95fa8c9d24d98e26afd2ca2103 Auto-merging sw/source/uibase/utlui/content.cxx Auto-merging vcl/unx/gtk3/gtkinst.cxx CONFLICT (content): Merge conflict in vcl/unx/gtk3/gtkinst.cxx error: could not apply 53d5f5e15c00... tdf#151387 Fix regression cause by tdf#149279 hint: After resolving the conflicts, mark them with hint: "git add/rm <pathspec>", then run hint: "git cherry-pick --continue". hint: You can instead skip this commit with "git cherry-pick --skip". hint: To abort and get back to the state before "git cherry-pick", hint: run "git cherry-pick --abort". Then I do: $ gedit vcl/unx/gtk3/gtkinst.cxx and find the string "<<<<<<<" which indicated conflicts. There are two places where the conflicts occur: ``` <<<<<<< HEAD gtk_tree_view_scroll_to_cell(m_pTreeView, path, nullptr, false, 0, 0); ======= gtk_tree_view_expand_to_path(m_pTreeView, path); gtk_tree_view_scroll_to_cell(m_pTreeView, path, nullptr, true, 0, 0); >>>>>>> 53d5f5e15c00 (tdf#151387 Fix regression cause by tdf#149279) ``` The code between "<<<<<<< HEAD" and "=======" are codes on current libreoffice-7-4 branch before your cherry-pick. The code betwen "=======" and ">>>>>>> 53d5f5e15c00" are codes added by your cherry-pick patch. As you can see in gtk_tree_view_scroll_to_cell one arg is changed to "true" in your patch, which indicates that it is changed to "true" on master branch but remains "false" on libreoffice-7-4 branch. You need to decide whether to apply the line "gtk_tree_view_expand_to_path" only, or apply the other line also.
Here is the git show of a local cherry pick I did to libreoffice-7-4 with merge conflicts resolved. Do I now do './logerrit submit libreoffice-7-4' ? commit 9c727ce0788b43a43fc5666ae8c3515f12ab279b (HEAD -> libreoffice-7-4) Author: Jim Raykowski <raykowj@gmail.com> Date: Fri Oct 7 02:18:05 2022 -0800 tdf#151387 Fix regression cause by tdf#149279 The gtk_tree_view_expand_to_path function not only expands all parent rows of path as necessary but also expands the children of the row of the path. This explains the difference seen between gtk3inst and salinst when a collapsed row is scrolled to. gtk3inst expands the collapsed row, salinst does not. The enhancement patch for tdf#149279 removed the gtk_tree_view_expand_to_path function from gtk_tree_view_scroll_to_row. This caused a regression in the styles tree. To fix the regression this patch reverts the removed gtk_tree_view_expand_to_path functions. To make the enhancement patch behave the same for gtk3 and sal, the scroll to row is collapsed after scrolling if that was it's state before. Change-Id: I3c3975a3f258c6c432eb866a1c712299e2faf5be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141048 Tested-by: Jenkins Reviewed-by: Jim Raykowski <raykowj@gmail.com> (cherry picked from commit 53d5f5e15c005d95fa8c9d24d98e26afd2ca2103) diff --git a/sw/source/uibase/utlui/content.cxx b/sw/source/uibase/utlui/content.cxx index cf2c9eb569cc..851eb0f75dd0 100644 --- a/sw/source/uibase/utlui/content.cxx +++ b/sw/source/uibase/utlui/content.cxx @@ -3933,7 +3933,13 @@ void SwContentTree::UpdateTracking() while (!weld::IsEntryVisible(*m_xTreeView, *xIter)) m_xTreeView->iter_parent(*xIter); } + // Assure the scroll to row is collapsed after scrolling if it was collapsed + // before. This is required here to make gtkinst scroll_to_row behave like + // salinst. + const bool bRowExpanded = m_xTreeView->get_row_expanded(*xIter); m_xTreeView->scroll_to_row(*xIter); + if (!bRowExpanded) + m_xTreeView->collapse_row(*xIter); } bRet = true; } diff --git a/vcl/unx/gtk3/gtkinst.cxx b/vcl/unx/gtk3/gtkinst.cxx index 690f39a50208..cd9bb63ae4ce 100644 --- a/vcl/unx/gtk3/gtkinst.cxx +++ b/vcl/unx/gtk3/gtkinst.cxx @@ -14946,6 +14946,7 @@ public: assert(gtk_tree_view_get_model(m_pTreeView) && "don't select when frozen, select after thaw. Note selection doesn't survive a freeze"); disable_notify_events(); GtkTreePath* path = gtk_tree_path_new_from_indices(pos, -1); + gtk_tree_view_expand_to_path(m_pTreeView, path); gtk_tree_view_scroll_to_cell(m_pTreeView, path, nullptr, false, 0, 0); gtk_tree_path_free(path); enable_notify_events(); @@ -15623,6 +15624,7 @@ public: disable_notify_events(); const GtkInstanceTreeIter& rGtkIter = static_cast<const GtkInstanceTreeIter&>(rIter); GtkTreePath* path = gtk_tree_model_get_path(m_pTreeModel, const_cast<GtkTreeIter*>(&rGtkIter.iter)); + gtk_tree_view_expand_to_path(m_pTreeView, path); gtk_tree_view_scroll_to_cell(m_pTreeView, path, nullptr, false, 0, 0); gtk_tree_path_free(path); enable_notify_events();
Yes, but I think you should mention the following in the commit message, so that others know there was a conflict and is resolved: conflicts: vcl/unx/gtk3/gtkinst.cxx Also make sure the "Change-Id" remains in the last block (as it already is in your diff above).
Jim Raykowski committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/d19d64b6a3e697fdbf7c0d05a318afddbc349bd4 tdf#151387 Fix regression cause by tdf#149279 It will be available in 7.4.3. 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.