Bug 106281 - Progress bar, on status line, no longer indicating progress
Summary: Progress bar, on status line, no longer indicating progress
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
: 111861 (view as bug list)
Depends on:
Blocks: File-Progress-Bar Macro-UNOAPI
  Show dependency treegraph
Reported: 2017-03-02 13:01 UTC by Alex Kempshall
Modified: 2022-04-08 07:11 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

This document can be used to test Progress Bar issue (11.39 KB, application/vnd.oasis.opendocument.text)
2017-03-02 13:05 UTC, Alex Kempshall
Results from bisect (2.43 KB, text/x-log)
2017-03-03 11:38 UTC, Alex Kempshall

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Kempshall 2017-03-02 13:01:31 UTC
In Writer when using a progress bar within a macro it should show progress by a coloured bar, in my case blue, moving steadily to the right.
With Master this is no longer the case. 

Steps to reproduce the problem.

Download the files ProgressBarTest.odt document from this bug report. 

Start LibreOffice writer with the document ProgressBarTest.odt downloaded in step 1. Note: this file contains a macro so be mindful that some security steps might need to be taken.

The document should open and will include the text “This is a test document” and a button called “ProgressBarTest”

The status bar, bottom of the window, should contain the following text -
“Page 1 of 1	5 words, 23 characters 	Default Style”

Run the ProgressBarTest macro by pressing the button “ProgressBarTest”

Expected results. 

The Status Bar will change to the text “Progressing n of 100”
where 'n' will be a number between 1 and 100. To the right of this text a blue line will rapidly move to the right until it uses all available space and 'n' will repeatedly increment by 1 until it reaches 100.

Actual results.

The Status Bar changes to the text “Progressing n of 100”
where 'n' is a number between 1 and 100. There is no blue line. However, 'n' is repeatedly  incremented by 1 until it reached 100.

Comment 1 Alex Kempshall 2017-03-02 13:05:17 UTC
Created attachment 131577 [details]
This document can be used to test Progress Bar issue

This document contains a button that calls a macro. This macro generates a progress bar on the status line. Well it does on all versions of LibreOffice upto an including 4.3.1.
Comment 2 Xisco Faulí 2017-03-02 13:30:17 UTC Comment hidden (obsolete)
Comment 3 Alex Kempshall 2017-03-02 14:29:03 UTC
Hi Xisco

Downloaded latest daily master build get no blue line in progress bar. The version is 

Build ID: 472f92421b1b15dc765714a7c657704812859868
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-03-01_23:20:29

Also confirmed on latest master pulled from git

Build ID: 7d2ec4c0136c054923947093e35f4ab074f2b550
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; 
Locale: en-GB (en_GB); Calc: group

For the problem with the button the document might be in “Design Mode”. Try toggling it.

Edit → Design Mode
Comment 4 Thomas Hackert 2017-03-02 15:16:00 UTC
Hello Alex, *,
thank you very much for reporting this bug :) I cannot - however - confirm it with

OS: Debian Testing AMD64
DE: XFCE 4.12
LO: Version:
Build-ID: 08750abc64a7ad82cac96adeb7a0bcdce7ac704d
CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-02-28_00:23:27
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

, sorry ... :( Does it change, if you start LO from command line with "SAL_USE_VCLPLUGIN=gen", "SAL_USE_VCLPLUGIN=gtk2" or "SAL_USE_VCLPLUGIN=gtk3" in front of /path/to/instdir/soffice? Which distro are you using and which DE/DM?
Comment 5 Alex Kempshall 2017-03-02 16:51:31 UTC
Hello Thomas

The progress bar works as expected with LO 5.3.1.

I'm using Slackware 14.2 and KDE 4.14.3

Using "SAL_USE_VCLPLUGIN=gen", "SAL_USE_VCLPLUGIN=gtk2" or "SAL_USE_VCLPLUGIN=gtk3" makes no difference the Progress Bar doesn't display the blue line moving to the right. Though they do change the "look" of the application overall especially  "SAL_USE_VCLPLUGIN=gen"

Comment 6 Alex Kempshall 2017-03-03 11:38:36 UTC
Created attachment 131598 [details]
Results from bisect

This is what I got -
 0b08eacd79a2133a07410dfb99bcc04bb9dd2199 is the first bad commit
commit 0b08eacd79a2133a07410dfb99bcc04bb9dd2199
Author: Jan-Marek Glogowski <glogow@fbihome.de>
Date:   Wed Feb 22 17:08:25 2017 +0100

    tdf#104482 Force updating progress bar on safe
    I don't know why the progress bar on load is handled differently
    then on safe. As a workaround, this converts all Flush() calls
    to Update() calls, but we should update the UI on safe correctly.
    Change-Id: I97d6fc5797d08e9556f7fa7f9f8110aef30b3772

:040000 040000 1b1c9252201f40b413813903009dd320ee195b0f b409c8b19a9925f29a49044779b059c4f0aa0678 M      vcl
Comment 7 Xisco Faulí 2017-03-03 12:11:04 UTC
Adding Cc: to Jan-Marek Glogowski
Comment 8 Xisco Faulí 2017-08-16 17:54:30 UTC
*** Bug 111861 has been marked as a duplicate of this bug. ***
Comment 9 Alex Kempshall 2017-08-26 10:15:11 UTC
As already reported this regression was brought about by commit 0b08eacd79a2133a07410dfb99bcc04bb9dd2199. This was to fix the problem whereby tdf#104482 Force updating progress bar on safe which was about the progress bar not operating when saving a file.

The above fix solved the problem of the missing progress bar when saving a file, but stopped the progress bar displaying when used in a macro to just indicate progress on some arbitrary function.

It appears that the above fix was to semi-backout commit 9f4af777a832d8a0b9a21d793d421fa6228131e0

When I reintroduced similar code to that which was removed in  9f4af777a832d8a0b9a21d793d421fa6228131e0 both the progress bar in the save dialog and the macro work as expected.
Comment 10 Luis 2017-09-15 23:25:54 UTC
Tested in windows 8.1 with LO version and the issue is not present.
Comment 11 Alex Kempshall 2017-09-19 12:11:19 UTC
Tested on Slackware 14.2 with LO Version:
Build ID: ffb4d7b16b386ba13f27722cd78406d5b5c5baca and the issue is not present.

The problem was fixed by patch 

> 4b44a42b6a54ddf57635fcdb9cf9c18c5e631ff1 Resolves: tdf#111865 ensure draw after SetProgressValue uses new value

Thanks to Caolán McNamara <caolanm@redhat.com> for fixing this.