Download it now!
Bug 90462 - Inconsistent behaviour of "Advance Slide" - "Automatically after:" in the Slide Transition sidebar
Summary: Inconsistent behaviour of "Advance Slide" - "Automatically after:" in the Sli...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
Keywords: bibisected, bisected, needsUXEval, regression
Depends on:
Reported: 2015-04-05 10:43 UTC by Matthew Francis
Modified: 2017-08-14 12:15 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2015-04-05 10:43:08 UTC
Split from bug 90349

The behaviour of "Advance Slide" - "Automatically after:" in the Slide Transition sidebar is inconsistent and does not seem very friendly.

- When "No transition" is selected, the "Automatically after:" field can be freely edited and is coerced to "0.00 sec" only after leaving the field. This seems reasonable to me

- When any transition is selected, the format is coerced over-enthusiastically to "0.00 sec" while you type. The visual and logical behaviour of this seems sub-optimal. Whether a digit is inserted or deleted when typing depends on the position of the cursor and the current content, which means the user has to keep a complex mental model of what the effect of a given combination of position/content/input will be. The user (or at least this user) would generally prefer to be able to add and delete characters at will to reach a desired number.
In addition, when a digit is forced to be overwritten, a digit is first displayed being inserted, then deleted (causing ugly flicker)

For instance,

("|" denotes the position of the cursor)
"1.00| sec", type Backspace x3 => "100.00 sec" (surprising)
"1|.00 sec", type Backspace, "4" => "40.00 sec" (surprising)
"1.|00 sec", type "1" => briefly "1.100 sec" => "1.10 sec" (ugly)

The only situation where the scheme which is currently attempted would make consistent sense is if the format (including the total number of digits) were truly fixed - e.g. always "000.00" - and attempts to delete the decimal point were ignored. However, I would suggest that the most reasonable behaviour is that of the current "No transition" case, i.e. no coercion while typing at all.

Additional suggestion: "Return" should format and confirm the currently input value
Comment 1 Matthew Francis 2015-04-05 10:43:22 UTC
For reference, the most recent behaviour occurs since commit
in bibisect 43all, which is probably one or both of the below commits

commit 1b2da3df5449f5bc517418cc632157780984e275
Author: David Tardon <>
Date:   Thu Feb 13 14:07:09 2014 +0100

    enable spin-size for NumericField too
    Change-Id: I77660572947f7a863982be7742cbcb1c784379ed

commit 78ff9d90f2a74792c437087ede11559c111c5c98
Author: David Tardon <>
Date:   Thu Feb 13 14:05:47 2014 +0100

    fdo#74468 fix timing of slide transitions
    Regression since commit 16428c9600964a4945cf6fd0d938dea047d1248b.
    Change-Id: Id274c21e08d10d2e727f3b5a3fd852cd297e4637
Comment 2 Matthew Francis 2015-04-05 10:46:41 UTC
Forwarding to UX for advice - as above, I feel this interface could be better than it is at present

Comment 3 V Stuart Foote 2015-04-05 15:34:00 UTC
Yup, there is a definite UI glitch in the widget used to set transition timer.

Timer input is affected on both 32-bit and 64-bit builds (at least on Windows) when any of the transitions has been selected for a slide.

Interesting in that if no slide transition is set--No transition--the Advance Slide -> Automatically after... widget behaves sanely.  

Lends to a simple work around, of resetting the transition to none, adjusting the timing, and then reapplying the transition.  But shouldn't have to do that.

@David T., thoughts why this gets munged when a transition is set?
Comment 4 Robinson Tryon (qubit) 2015-12-13 11:12:13 UTC Comment hidden (obsolete)
Comment 5 Robinson Tryon (qubit) 2016-08-25 04:44:54 UTC Comment hidden (obsolete)
Comment 6 Xisco Faulí 2016-11-12 14:10:16 UTC
Adding keyword 'bisected' as the problem has been narrowed to 2 commits in comment 1
Comment 7 Heiko Tietze 2017-08-14 12:15:22 UTC
Cannot follow. Advance Slide > Automatically after is a numerical edit defaulting to 1.00s. I can edit the field without glitches under Windows 7 - it depends on the OS/DE how numerical steppers are handled, i.e. when exactly the auto adjustment starts, meaning onkeyup or onleave. Setting the ticket to NAB.