Bug 133206 - UI: Closing a style dialog by pressing OK changes the focus in the styles sidebar to the active style where the cursor stands
Summary: UI: Closing a style dialog by pressing OK changes the focus in the styles sid...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
: 133468 (view as bug list)
Depends on:
Blocks: Writer-Styles
  Show dependency treegraph
Reported: 2020-05-20 20:36 UTC by Telesto
Modified: 2023-05-30 05:04 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Screencast (975.85 KB, video/mp4)
2020-08-04 09:25 UTC, Telesto
Screencast (4.82 MB, video/mp4)
2020-08-04 10:07 UTC, Telesto
video testing the bug (344.42 KB, video/mp4)
2023-05-30 05:02 UTC, BogdanB

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-05-20 20:36:13 UTC
UI: Closing a dialog by pressing OK changes the focus in the style dialog to  Default paragraph style

Steps to Reproduce:
1. Open Writer
2. Sidebar -> Styles
3. Select the footnote style (blue bar)
4. Right Click -> Modify
5. Press OK -> Focus jumps to Default paragraph style

Actual Results:
Focus jumps to Default paragraph style

Expected Results:
Should stay at footnote style (in this case)

Reproducible: Always

User Profile Reset: No

Additional Info:
Version: (x64)
Build ID: 442c7b95e2ee94b66a9854d0cb22f8ecb76532c6
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; 
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2020-05-20 20:37:14 UTC
Bisected to 
author	Caolán McNamara <caolanm@redhat.com>	2016-11-05 20:28:27 +0000
committer	Caolán McNamara <caolanm@redhat.com>	2016-11-07 21:04:50 +0000
commit 64a708cba9b954afe3331f63c58218eb53b3d0ce (patch)
tree ddc1bea3b63f32a1c6d377c1d1dd7aee0803fb70
parent f01c49c4a89ecad2376fd0023625186e5cac642e (diff)
Revert "Reverts a commit series that cripple windows ci."
with addition of...

- svxlo-SvxColorListBox
+ svxcorelo-SvxColorListBox

This reverts commit db380aab1063e8a5e40111c40ee9f7921aa82601.

$ git bisect bad f26fbbd08d0792fd5fc361faaa1cf183824bdd44 is the first bad commit
commit f26fbbd08d0792fd5fc361faaa1cf183824bdd44
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Mon Nov 7 13:28:42 2016 -0800

    source 64a708cba9b954afe3331f63c58218eb53b3d0ce

    source 64a708cba9b954afe3331f63c58218eb53b3d0ce

:040000 040000 f2fb0556bd23daaca83f666bd70d00dea47cedc6 c527b21a759e98b9ecbe441e9fc4a82bfc6768f8 M      instdir
Comment 2 bhagwat singh 2020-05-21 14:33:09 UTC Comment hidden (spam)
Comment 3 Telesto 2020-05-22 07:28:19 UTC
Adding CC to Caolán McNamara

Bug isn't confirmed, yet.. but has to do with the styles sidebar (similar to the other two). So maybe one take..
Comment 4 Caolán McNamara 2020-05-22 07:54:33 UTC
is this even a bug ?
Comment 5 Telesto 2020-05-22 09:00:05 UTC
(In reply to Caolán McNamara from comment #4)
> is this even a bug ?

In my opinion yes, but.. lets wait for QA.. sorry for the annoyance
Comment 6 Telesto 2020-06-14 19:25:18 UTC
Bug or no bug..  Compare prior to 5.3 and after 5.3
Comment 7 Buovjaga 2020-06-16 18:56:51 UTC
Well, it would be nice to preserve the selection, so let's set to NEW.
Comment 8 Thomas Lendo 2020-08-03 21:51:31 UTC
This is a general question how to solve such things and what do users expect.

First, the behavior is not consistent between style types and LibO components. I could reproduce this issue with Calc and Draw a few times but very rare. Also in Writer it's not always true.

Second, the focus moves to the style that is active for the text/object where the cursor stands. If your cursor is in a text that is formatted with paragraph style Endnote and character style Emphasis and you edit another paragraph/character style, then the focus goes back to Endnote (paragraph) or Emphasis (character) style in the styles sidebar.

This isn't bad by design as this is the normal behavior of the styles sidebar items: highlighting the style where the cursor stands. This could be changed to: If the user selects another style (by right or left mouse click or keyboard) then this style should be selected until the user selects another style or the user changes the cursor position. Then the style will be selected in the styles sidebar that corresponds with the text/object.

Ideally this behavior should be the same in all LibO components.
Comment 9 Telesto 2020-08-03 22:18:33 UTC
*** Bug 133468 has been marked as a duplicate of this bug. ***
Comment 10 Heiko Tietze 2020-08-04 07:50:10 UTC
Cannot confirm. Cursor is on text with PS = Caption, I right click PS Footnote (node is selected), modify something and press okay, and the currently active style is highlighted, which is still Caption.

The issue with active vs. selected nodes in the stylist is discussed in bug 94427. You can also single click an entry and nothing happens. The proposal in the duplicate (@QA: my take here) is to keep the active style highlighted even when another node is selected, maybe per grey background (there should be a default color for this).
Comment 11 Telesto 2020-08-04 09:25:01 UTC
Created attachment 163927 [details]
Comment 12 Heiko Tietze 2020-08-04 09:32:02 UTC
(In reply to Telesto from comment #11)
> Created attachment 163927 [details]
> Screencast

If the (empty) paragraph has the Default PS this item will be highlighted after editing. Try with meaningful content.
Comment 13 Telesto 2020-08-04 10:07:29 UTC
Created attachment 163929 [details]

To demonstrate even inconsistency's
Comment 14 Telesto 2020-08-04 10:08:12 UTC
(In reply to Heiko Tietze from comment #12)
> (In reply to Telesto from comment #11)
> > Created attachment 163927 [details]
> > Screencast
> If the (empty) paragraph has the Default PS this item will be highlighted
> after editing. Try with meaningful content.

And you might also use LibreOffice 5.2 for comparison matters :-)
Comment 15 Justin L 2021-03-24 06:14:42 UTC
Whether this is a bug or not depends on your workflow I'd say. If you are walking through the styles one by one and changing something, then this would be annoying.

However, trying to fix this would be dangerous because in general the current paragraph SHOULD be highlighted. So the "jump to the current paragraph's style on refresh" would need to be context aware and ignore that step under certain conditions. That sounds like a disaster in the making - I vote for WONTFIX.
Comment 16 QA Administrators 2023-03-25 03:24:03 UTC Comment hidden (obsolete)
Comment 17 BogdanB 2023-05-30 05:02:18 UTC
Created attachment 187598 [details]
video testing the bug

In 7.6 is moving the double-clicked style to the top.
Comment 18 BogdanB 2023-05-30 05:04:35 UTC
And with edit and OK is going to Default Style.