Description: Additional page added when opening a certain "open text template" in multipage view twice Steps to Reproduce: 1. Open attachment 162400 [details] (bug 134298) -> A 2 page document expected 2. Zoom out -> say to 55% 3. File -> Open -> Open the same file again 4. Zoom out -> Document has 3 pages FWIW: the initial bug 134298 is probably of relevance Actual Results: 3 pages on the second opening Expected Results: 2 pages Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c4a58634753a84b09f20f7271d6525a6656522d3 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: threaded
Reproducible Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: daf30c29be67b8b8fa361b0efd1a6cdbe087b6f8 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
It's a regression. Not in 4.4.7.2. Bibisect might be impossible due to bug 134298
Tried to bibisect, results are inconsistent. I thought it started in 7.2, I got to a bibisect result but checked HEAD~1 about 8 times before it manifested again. In my tests, it can sometimes manifests at first fileopen, another time it took me 23 times to see it. All I know for sure is that it's bad in linux-64-7.2 repo at fc00ef68e source cdbf09681b7c66c3d3c1d5c8086bd57e23f7939c Also repro in recent master build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 66da786bdd4588b31755058acf46034c2056215c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Steps for more consistent results welcome.