Bug 159168 - Character style: "No Character Style" won't be shown when "Applied Styles" is chosen
Summary: Character style: "No Character Style" won't be shown when "Applied Styles" is...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.2.0.1 rc
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on: 158504
Blocks: Sidebar-Properties-Character
  Show dependency tree / graph
 
Reported: 2024-01-13 14:47 UTC by Robert Großkopf
Modified: 2024-04-03 06:55 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2024-01-13 14:47:10 UTC 
Open a new Writer document with LO 24.2.0.1.
Write a word, mark it an go to sidebar.
Choose "Styles" → "Character Styles".
Choose "No Character Style".

Here is the first irritating moment: Why isn't "No Character Style" chosen? What style should be the style for a new entered text content?

Now switch to "Applied Styles" at the bottom of the sidebar for styles.
No character style is shown.
Switch back to "All Styles".
No character style seems to be connected to text content.

I mostly work with "Applied Styles". It will reduce the styles to the styles I need for this special document. But it shouldn't exclude the default "No Character Styles", because it is in use for most of the text content and I need this for setting back a character style to default.

Switching to Paragraph Styles will show the default paragraph style without any problem.

This buggy behavior of character style appears under 
Version: 24.2.0.1 (X86_64) / LibreOffice Community
Build ID: b4d45829793cddfe67b58a53f495528c75738d8a
CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: en-US
Calc: threaded

Won't appear in LO 7.6.4.1 on the same system. So a regression.
Comment 1 m_a_riosv 2024-01-14 11:10:01 UTC 
Reproducible
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 25276df12abd9d002f7f899900434617b256f745
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Comment 2 Chris Kirkland 2024-01-31 17:56:39 UTC 
This bug also affects 24.2.0.2 and 24.2.0.3 with Windows 11.
Comment 3 BogdanB 2024-03-25 18:54:11 UTC 
I also miss this function.

I tried to bibisect this bug, but I get:
Bisecting: 144 revisions left to test after this (roughly 7 steps)
[9a513a30acfa0862303c46e83c81da8b1819944e] source c1586ef57b5770f80ef200ab38ff4538c2dfb145
soffice.bin: ../../../../src/cairo-surface.c:930: cairo_surface_reference: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed.
soffice.bin: ../../../../src/cairo-surface.c:930: cairo_surface_reference: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed.
soffice.bin: ../../../../src/cairo-surface.c:930: cairo_surface_reference: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed.

But the document recovery continue forever...
Comment 4 BogdanB 2024-03-25 18:55:37 UTC 
If there is a way to bibisect avoiding this CAIRO assertion, I will be glad to bibisect again.
Comment 5 Kira Tubo 2024-04-03 06:55:37 UTC 
Seems to be related to Bug 158504. I verified that this issue was also introduced at the same commit: 
https://git.libreoffice.org/core/+/140079362502408c75ceee67e86d779f61c0ac1b. 

Not sure if we should keep this open to use as an additional test point once 158504 is fixed...