One of the filter options for the Styles list in the Styles sidebar is "Applied Styles". If you create a new document, you'll see the the "Default Paragraph Style" does appear when applying the filter, but - "Default Page Style" does not appear in the Page Styles category, despite the first (and only) page using it. This remains the case even if one adds content, including multiple paragraphs on multiple pages.
Seen with: Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 516f800f84b533db0082b1f39c19d1af40ab29c8 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US
Seems to be a regression: with the "applied styles" option in an empty document the default page style is shown in Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: es-ES (es_ES.UTF-8); UI: es-ES Calc: threaded but not in Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 05d5181e2c19aca7e6098217ddb7065e02819a53 CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded [Changing VERSION field and setting as NEW]
Seems to me the default PgS is not the "Default PgS" anymore. => BUG
Tring to bibisect, but getting bogdan@bogdan-IdeaCentre-AIO-3-24ALC6:~/Documente/Bibisect/24.2/linux-64-24.2$ git bisect good && ./instdir/program/soffice Bisecting: 288 revisions left to test after this (roughly 8 steps) [95947107aa8554151ef8834a326dba9886801a14] source 252132d9752964a4aa82567b6a3ca8cd7df5ccfb 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. soffice.bin: ../../../../src/cairo-surface.c:930: cairo_surface_reference: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed. And I get crash, and I can not escape from here with a new document in order to bibisect.
(In reply to BogdanB from comment #4) > [95947107aa8554151ef8834a326dba9886801a14] source > 252132d9752964a4aa82567b6a3ca8cd7df5ccfb Any idea, Gabor?
Hm, I don't experience the issue from comment 4 bibisecting on win64-24.2. Could be specific to Linux. --------------------- Bibisected win64-24.2. Added Bjoern Michaelsen to cc. Regression introduced at commit: https://git.libreoffice.org/core/+/140079362502408c75ceee67e86d779f61c0ac1b --------------------- commit 140079362502408c75ceee67e86d779f61c0ac1b [log] author Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org> Wed Aug 09 11:34:00 2023 +0200 committer Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org> Fri Sep 01 00:05:28 2023 +0200 tree 192aac811efa24025ce2059c89a8141a059799d6 parent 345b214c37d1f645dd0e6e084358f8ca81d9ed66 [diff] --------------------- commit ebea09b5c456572c2843a8dd0da2aa09649f149b Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Sep 13 18:17:10 2023 -0700 source 140079362502408c75ceee67e86d779f61c0ac1b --------------------- Reproduced on: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community CPU threads: 6; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
*** Bug 159294 has been marked as a duplicate of this bug. ***
This bibisect from Comment 4 seems to be misleading: I just compiled 345b214c37d1f645dd0e6e084358f8ca81d9ed66 (which is the parent of 140079362502408c75ceee67e86d779f61c0ac1b) on Linux and the default page style does _not_ show up as an applied style. So 140079362502408c75ceee67e86d779f61c0ac1b is NOT causing this regression: it was there before. This might either be a heisenbug or it might have been a fumble in the bibisect in Comment 6: Given that with a 345b214c37d1f645dd0e6e084358f8ca81d9ed66 build on Linux this is not reproducible, the root cause has to be in 345b214c37d1f645dd0e6e084358f8ca81d9ed66 or in the commits before. Even given the cairo errors mentioned in Comment 4, maybe it is worthwhile to retry a bibisect. This could also be done on Linux with setting "SAL_USE_VCL_PLUGIN=gen" to avoid the cairo breakage. => Removing the bibisected/bisected keywords for that.
Created attachment 195151 [details] unittest unittest to check if the default page style is considered "used", fails on 345b214c37d1f645dd0e6e084358f8ca81d9ed66 -- as does manual testing of "is the default page style showing up in the sidebar with the 'applied' filter". (Note: I havent tested this to succeed on older versions, but would expect it to succeed -- otherwise we would not have this regression bug)
(In reply to BogdanB from comment #4) > Tring to bibisect, but getting > [95947107aa8554151ef8834a326dba9886801a14] source > 252132d9752964a4aa82567b6a3ca8cd7df5ccfb > soffice.bin: ../../../../src/cairo-surface.c:930: cairo_surface_reference: > Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed. > And I get crash, and I can not escape from here with a new document in order > to bibisect. I just tried to bibisect, this reference is what I was getting from terminal. It's not a final result of the bibisect process. Sorry.
(In reply to BogdanB from comment #4) > Tring to bibisect, but getting > ... > soffice.bin: ../../../../src/cairo-surface.c:930: cairo_surface_reference: > Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed. > > And I get crash, and I can not escape from here with a new document in order > to bibisect. I get no crash with gen VCL plugin, you could try with SAL_USE_VCLPLUGIN=gen ./soffice. (In reply to Kira Tubo from comment #6) > Regression introduced at commit: > https://git.libreoffice.org/core/+/140079362502408c75ceee67e86d779f61c0ac1b I get the same result in Linux with the 24.2 bibisect build. If Björn is positive this regression isn't coming from his commit, I'm marking this as notBibisectable.
(In reply to Aron Budea from comment #11) > (In reply to Kira Tubo from comment #6) > > Regression introduced at commit: > > https://git.libreoffice.org/core/+/140079362502408c75ceee67e86d779f61c0ac1b > I get the same result in Linux with the 24.2 bibisect build. Same for me, I can confirm Kira's comment 6 bibisect with the linux-64-24.2 repo. I used SAL_USE_VCLPLUGIN=gen to avoid the crash, with a new profile each time. See also bug 159168 comment 10, in which I could also confirm Kira's bibisect. Björn, I'm wondering if the inability to confirm on your end is related to the default template for Writer, or something about locale? For me: Steps: 1. Open new document in Writer with new profile 2. Select "Applied Styles" in Sidebar Page Styles deck Result: - At 345b214c37d1f645dd0e6e084358f8ca81d9ed66: Default Page Style is listed in Applied Styles. - At 140079362502408c75ceee67e86d779f61c0ac1b: Default Page Style is not listed anymore in Applied Styles. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 140079362502408c75ceee67e86d779f61c0ac1b CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: x11 Locale: en-AU (en_AU.UTF-8); UI: en-US Note that this is _without_ applying the style in the first place. If you do apply it, you can see it listed both before and after that commit. (But modifying the page's style with Format > Page Style shows that the page uses Default Page Style without needing to apply it, so one shouldn't need to "re-apply" it to see it listed in the Applied styles.)
(In reply to Stéphane Guillou (stragu) from comment #12) > Steps: > 1. Open new document in Writer with new profile > 2. Select "Applied Styles" in Sidebar Page Styles deck > > Result: > - At 345b214c37d1f645dd0e6e084358f8ca81d9ed66: Default Page Style is listed > in Applied Styles. > - At 140079362502408c75ceee67e86d779f61c0ac1b: Default Page Style is not > listed anymore in Applied Styles. Can confirm now. > Björn, I'm wondering if the inability to confirm on your end is related to > the default template for Writer, or something about locale? Must have been an unclean build or something, sorry.