Description: Page counter isn't always updated automatically Steps to Reproduce: 1. Open the attached file 2. CTRL+A & CTRL+C 3. CTRL+N (New document) 4. CTRL+V (wait until the word count is finished. Page will scroll down, page 10-11) Actual Results: Page counter shows 10 out 11 Expected Results: Should be 369 of 369 Reproducible: Always User Profile Reset: No Additional Info: Version: 6.2.0.0.alpha0+ Build ID: 7d242f3bd7277236046f90d3f32b9792fd8ea97b CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-09-18_23:43:19 Locale: nl-NL (nl_NL); Calc: CL
Created attachment 145051 [details] Example file
Can't confirm it. It took a few seconds until the text appeared, but the document scrolled down until the end of the document and page counter shows 377 of 377. Version: 6.2.0.0.alpha0+ (x64) Build ID: 62cd86977ca41677c56fb2d1f97bb1c5cbdbd416 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-20_02:34:32 Locale: en-US (de_DE); Calc: CL
(In reply to Dieter Praas from comment #2) > Can't confirm it. It took a few seconds until the text appeared, but the > document scrolled down until the end of the document and page counter shows > 377 of 377. > > Version: 6.2.0.0.alpha0+ (x64) > Build ID: 62cd86977ca41677c56fb2d1f97bb1c5cbdbd416 > CPU threads: 4; OS: Windows 10.0; UI render: GL; > TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-20_02:34:32 > Locale: en-US (de_DE); Calc: CL A) Please try it without OpenGL (no issue with OpenGL enabled) B) Weird. My page count really is 369 instead of 377
Result with Open GL disabled: Page count shows 10 of 11 for araund 3 seconds and than 377 of 377. But I think this is differnt from your result, Telesto?
@Buovjaga Slightly outside the scope of this bug. But how many pages doesn't the document have? Dieter is reporting 377; i'm seeing 369 pages @Dieter Strange, the steps did work initially. It seems to work now. So a small change in the STR 1. Open the attached file 2. CTRL+A & CTRL+C 3. CTRL+N (New document) 4. Press CTRL+V twice (2x). Page counter stops at 378 of 379 pages
(In reply to Telesto from comment #5) > @Buovjaga > Slightly outside the scope of this bug. But how many pages doesn't the > document have? Dieter is reporting 377; i'm seeing 369 pages > > @Dieter > Strange, the steps did work initially. It seems to work now. So a small > change in the STR > > 1. Open the attached file > 2. CTRL+A & CTRL+C > 3. CTRL+N (New document) > 4. Press CTRL+V twice (2x). Page counter stops at 378 of 379 pages Original shows 369. After pasting once, 377. Pasting twice, 388, but after some action, 754. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 05db125c57ea3c8f04a304561209c32cc5c45a67 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on September 17th 2018
(In reply to Buovjaga from comment #6) > Original shows 369. After pasting once, 377. Pasting twice, 388, but after > some action, 754. > > Arch Linux 64-bit > Version: 6.2.0.0.alpha0+ > Build ID: 05db125c57ea3c8f04a304561209c32cc5c45a67 > CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; > Locale: fi-FI (fi_FI.UTF-8); Calc: threaded > Built on September 17th 2018 Setting to confirmed based on you're conformation: Pasting twice, 388, but after some action, 754. Cause of the page count difference: A4 vs letter, I suppose..
Tested on version: 6.2.0.0.alpha0+. Page 369 of 369. The document is A4 not Letter. Inital document have 369, the new document gets the same page size, so the number of pages remain the same. 369. version: 6.2.0.0.alpha0+ Build ID: e005ab5d40d358adb75a64e140d46f4bf605647d CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-09-15_02:08:38 Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
I tested also on Version: 6.1.1.0.0+ Build ID: 5a56b72413d5f555c854e36d3bd2fd50ec21644c CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-6-1, Time: 2018-08-15_02:45:13 Locale: ro-RO (ro_RO.UTF-8); Calc: group threaded Here the speed of pasting the text is much better. But here I notice the error with pages. Initial document have 369 pages. The new document have 337 pages. I check the settings for both Page Properties, but they seem the same. A4, 21 cm, 29,7 cm, the same orientation, the same margins, but different number of pages...
The problem is already in the oldest 3.5.0 in our bibisect repos, but in 3.3.0 it is not seen. The page counts still make sense in 3.5.0 and 3.6.7. Meaning 369 x 2 == 738 and not 754
(In reply to Buovjaga from comment #10) > The problem is already in the oldest 3.5.0 in our bibisect repos, but in > 3.3.0 it is not seen. The page counts still make sense in 3.5.0 and 3.6.7. > Meaning 369 x 2 == 738 and not 754 Please create a different report for that ;-). This is only about the counter not updating without a user interaction
Okay, so this seems like a bug report that gets us nowhere.
The page counter not continuously updating (10-11 for a while) and not updating until a user action started with: author Michael Stahl <mstahl@redhat.com> 2017-06-09 22:29:49 +0200 committer Michael Stahl <mstahl@redhat.com> 2017-06-10 00:10:46 +0200 commit d76fa3f5a5ae1d781ddd7457607a5773373d4f01 (patch) tree 7b56b12b9d614c04b3ef5b70491f625482148a81 parent 2ca0360a6c75959bf61bd2ee0ef96b2729369a15 (diff) sw: use DisableCallbackAction here also This should also fix tdf#91602 and appears more consistent. https://cgit.freedesktop.org/libreoffice/core/commit/?id=d76fa3f5a5ae1d781ddd7457607a5773373d4f01
Created attachment 145100 [details] Bibisect log
(In reply to Telesto from comment #13) > The page counter not continuously updating (10-11 for a while) and not > updating until a user action started with: > > author Michael Stahl <mstahl@redhat.com> 2017-06-09 22:29:49 +0200 > committer Michael Stahl <mstahl@redhat.com> 2017-06-10 00:10:46 +0200 > commit d76fa3f5a5ae1d781ddd7457607a5773373d4f01 (patch) > tree 7b56b12b9d614c04b3ef5b70491f625482148a81 > parent 2ca0360a6c75959bf61bd2ee0ef96b2729369a15 (diff) > sw: use DisableCallbackAction here also > This should also fix tdf#91602 and appears more consistent. > > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=d76fa3f5a5ae1d781ddd7457607a5773373d4f01 Adding Cc: to Michael Stahl
Repro with Version: 6.4.0.0.alpha0+ (x86) Build ID: c2cb467a1e5194c56bb65706b7965fb2c9241b8f CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-06-29_00:11:35 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: threaded
Looks fixed Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: d7f734db2c078ced3ce08ad58cd816a79abe3bcf 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