Bug 71409 - Excessive duplicate accessible focused events for Calc input line [a11y]
Summary: Excessive duplicate accessible focused events for Calc input line [a11y]
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.2.3 release
Hardware: Other All
: highest critical
Assignee: Dennis Francis
QA Contact:
URL:
Whiteboard: 5.4.3.2target:5.4.0 target:5.3.2 targ...
Keywords: accessibility, bibisected, bisected, regression
: 108053 (view as bug list)
Depends on:
Blocks: a11y Calc-Formula-Bar
  Show dependency treegraph
 
Reported: 2013-11-08 23:59 UTC by Joanmarie Diggs
Modified: 2017-09-16 17:37 UTC (History)
22 users (show)

See Also:
Crash report or crash signature:


Attachments
accessible-event listener (655 bytes, text/x-python)
2013-11-08 23:59 UTC, Joanmarie Diggs
Details
Backtrace - addAccessibleEventListener (AtkListener) (16.18 KB, text/plain)
2015-11-05 16:03 UTC, Niklas Johansson
Details
Backtrace - addAccessibleEventListener (DocumentFocusListener) (30.02 KB, text/plain)
2015-11-05 16:04 UTC, Niklas Johansson
Details
Backtrace - removeAccessibleEventListener (DocumentFocusListener) (37.24 KB, text/plain)
2015-11-05 16:05 UTC, Niklas Johansson
Details
accessible-event listener adjusted for python3 (720 bytes, text/x-python)
2016-11-13 17:09 UTC, Kohei Yoshida
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs 2013-11-08 23:59:38 UTC
Created attachment 88914 [details]
accessible-event listener

Steps to reproduce:
1. Launch the attached accessible event listener in a terminal
2. Launch Calc
3. Press F2 followed by Escape
4. Repeat Step 3 several times

Expected results: There would not be duplicate accessible focused events.

Actual results: The number of duplicate accessible focused events grows with each repetition.

Impact: The more cells which the user edits, the more sluggish his/her Calc + Assistive Technology user experience becomes.

(I'll build LibreOffice and, if I am successful, will verify that this issue persists in master. But experience over the years has proven that until it's reported by me or an Orca user, the problem persists.)

========================
PRESSED: F2
  object:state-changed:focused   False  [table | Sheet Sheet1]
  object:state-changed:focused   True   [text frame | Cell A3]
  object:state-changed:focused   True   [paragraph | ]
  object:state-changed:focused   True   [paragraph | ]
RELEASED: F2
PRESSED: Escape
  object:state-changed:focused   False  [paragraph | ]
  object:state-changed:focused   False  [paragraph | ]
  object:state-changed:focused   True   [text frame | Input line]
  object:state-changed:focused   True   [text frame | Input line]
  object:state-changed:focused   False  [paragraph | ]
  object:state-changed:focused   False  [text frame | Cell A3]
  object:state-changed:focused   True   [table | Sheet Sheet1]
  object:state-changed:focused   False  [text frame | Input line]
  object:state-changed:focused   False  [text frame | Input line]
  object:state-changed:focused   True   [paragraph | ]
  object:state-changed:focused   True   [paragraph | ]
RELEASED: Escape
PRESSED: F2
  object:state-changed:focused   False  [paragraph | ]
  object:state-changed:focused   False  [paragraph | ]
  object:state-changed:focused   False  [paragraph | ]
  object:state-changed:focused   True   [text frame | Input line]
  object:state-changed:focused   True   [text frame | Input line]
  object:state-changed:focused   True   [text frame | Input line]
  object:state-changed:focused   False  [table | Sheet Sheet1]
  object:state-changed:focused   True   [text frame | Cell A3]
  object:state-changed:focused   False  [text frame | Input line]
  object:state-changed:focused   False  [text frame | Input line]
  object:state-changed:focused   False  [text frame | Input line]
  object:state-changed:focused   True   [paragraph | ]
  object:state-changed:focused   True   [paragraph | ]
  object:state-changed:focused   True   [paragraph | ]
  object:state-changed:focused   True   [paragraph | ]
RELEASED: F2
PRESSED: Escape
  object:state-changed:focused   False  [paragraph | ]
  object:state-changed:focused   False  [paragraph | ]
  object:state-changed:focused   False  [paragraph | ]
  object:state-changed:focused   False  [paragraph | ]
  object:state-changed:focused   True   [text frame | Input line]
  object:state-changed:focused   True   [text frame | Input line]
  object:state-changed:focused   True   [text frame | Input line]
  object:state-changed:focused   True   [text frame | Input line]
  object:state-changed:focused   False  [paragraph | ]
  object:state-changed:focused   False  [text frame | Cell A3]
  object:state-changed:focused   True   [table | Sheet Sheet1]
  object:state-changed:focused   False  [text frame | Input line]
  object:state-changed:focused   False  [text frame | Input line]
  object:state-changed:focused   False  [text frame | Input line]
  object:state-changed:focused   False  [text frame | Input line]
  object:state-changed:focused   True   [paragraph | ]
  object:state-changed:focused   True   [paragraph | ]
  object:state-changed:focused   True   [paragraph | ]
  object:state-changed:focused   True   [paragraph | ]
RELEASED: Escape
Comment 1 Joanmarie Diggs 2013-11-09 01:37:24 UTC
(In reply to comment #0)

> (I'll build LibreOffice and, if I am successful, will verify that this issue
> persists in master. But experience over the years has proven that until it's
> reported by me or an Orca user, the problem persists.)

Confirmed. This problem persists in master:

   LibreOfficeDev 4.2
   Version: 4.2.0.0.alpha1+
   Build ID: e9fdc84698a19e0ff2be9d676c84cc214cbc4f3d

Also bumping the importance from medium to high.
Comment 2 m.a.riosv 2013-11-09 01:58:16 UTC
Hi Joanmarie, thanks for reporting.

Thanks to this report I have can identified the issue I was having working with calc, after a while working with a file enter data becomes slower with the time. It seemed a question of time working with the spreadsheet. 

But it is possible to reproduce using repeatedly F2 and [Enter], more visible if there is a formula in the cell. Doesn't happen pasting in a cell.

I was not able find so far as to reproduce the problem.

Reproducible:
Wint7x64Ultimate
Version 4.0.6.2 (Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24)
Version: 4.1.4.0.0+ Build ID: d6ee64b75581cbeb92534271ee6f4e87f07aa5c
Version: 4.2.0.0.alpha0+ Build ID: df21d317dacc4533ac999f3c3088765393842676
                 TinderBox: Win-x86@42, Branch:master, Time: 2013-11-05_00:13:53

Added to Mab 4.0
Comment 3 Joanmarie Diggs 2013-11-09 17:44:21 UTC
You can reproduce this problem on the Mac too. And in a way that you can clearly see the impact this bug has on end users.

Steps to reproduce (basically the same as the opening report):
1. Launch LibreOffice and get into Calc
2. Launch the VoiceOver screen reader with Cmd+F5
3. Press F2 followed by Escape
4. Repeat step 3

Each time you press F2, VoiceOver will say "edit text" and when you press Escape it will include the cell name (e.g. "Cell A1 edit text"). As you continue repeating step 3:

The first thing you'll notice is an increasing delay in the amount of time it takes for VoiceOver to announce that you are back in the cell (the "Cell A1 edit text" message).

After a few more repetitions, before you get the message that you are back in the cell, VoiceOver announces "LibreOffice busy". As you continue repeating step 3, there is an increasing delay between the time you hear "LibreOffice busy" to the time you are told you are back in the cell.
Comment 4 V Stuart Foote 2013-11-22 00:34:52 UTC
confirmed in Linux kernel 2.6.32-358.23.2.el6.x86_64 with Gnome v2. DE and LODev

Version: 4.2.0.0.alpha1+
Build ID: f99736820a23cb7e37139607713658dea1c69dd4
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2013-11-17_23:56:22
Comment 5 m.a.riosv 2013-12-09 22:36:56 UTC
Seems fixed in:

Win7x64Ultimate
Version: 4.2.0.0.beta2+ Build ID: 02180aed7dc0b8c5f9cc23b319adc2386a9aab69
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2013-12-08_08:48:31

but remains in:
Version: 4.1.5.0.0+ Build ID: 812963c5ff6e1c4685eddb830a82a69a3801d82
Comment 6 Björn Michaelsen 2014-01-17 09:58:43 UTC
(This is an automated message.)

Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Comment 7 stragu 2014-02-13 23:22:32 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
Comment 8 tommy27 2014-05-02 14:48:04 UTC
(In reply to comment #5)
> Seems fixed in:
> 
> Win7x64Ultimate
> Version: 4.2.0.0.beta2+ Build ID: 02180aed7dc0b8c5f9cc23b319adc2386a9aab69
> TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2013-12-08_08:48:31
> 
> but remains in:
> Version: 4.1.5.0.0+ Build ID: 812963c5ff6e1c4685eddb830a82a69a3801d82

4.1.x is now END OF LIFE (latest release is 4.1.6).

if you confirm the issue is gone in any of 4.2.x final releases we may mark this as RESOLVED WORKSFORME
Comment 9 m.a.riosv 2014-05-02 17:41:54 UTC
As I know it's long to be solved.
I forgot to report here my last verifications:

- To see the problem is needed to install with accessibility tools (at the end of installation).
- Disable the option Menu/Tools/LibreOffice/Accessibility/Miscellaneous options - Support assistive technology tools it's no possible, restarting it's enable again.

It's truly a pain work in calc with this issue, specially with a bit large spreadsheets.

I need to review again and report.

Please retain as MAB for now.
Comment 10 m.a.riosv 2014-05-02 22:31:00 UTC
Still reproducible with:
Win7x64Ultimate
Version: 4.2.4.1 Build ID: d4c441391e20647b3d2e8dde4d20aa868e77e515
Version: 4.2.5.0.0+ Build ID: 59906c3d54e6541185f4bf85b1d1c70530198059
   TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-04-30_09:30:13

With an install from scratch, installing Support assistive technology tools, there are not activated by default. And the option to enable/disable "Support assistive technology" works fine after restart LibreOffice.

IMO it must stay at MAB, for me calc is near to unusable with Accessibility tools activated.
Comment 11 V Stuart Foote 2014-05-02 22:37:45 UTC
moving to MAB 4.2 with close of MAB 4.1
Comment 12 tommy27 2014-12-07 08:15:29 UTC
please retest with LO 4.3.4.1 or 4.4.0.0 beta2
if bug is still reproducible please move this bug to mab4.3 list since 4.2.x is EOL
Comment 13 Robinson Tryon (qubit) 2014-12-07 18:23:31 UTC
CONFIRMED in LO 4.4.0.0.beta2 and LO 4.3.5.1 on Ubuntu 14.04

(In reply to Joanmarie Diggs from comment #0)
> Steps to reproduce:
> 1. Launch the attached accessible event listener in a terminal

Needed to install python-pyatspi package to use the listener.

> 2. Launch Calc
> 3. Press F2 followed by Escape
> 4. Repeat Step 3 several times
> 
> Expected results: There would not be duplicate accessible focused events.
> 
> Actual results: The number of duplicate accessible focused events grows with
> each repetition.

CONFIRMED: This still affect the LibreOffice 4.3 and 4.4 branches.
Comment 14 tommy27 2014-12-07 18:48:40 UTC
thanks Robinson for confirmation, however MAB rules say that a bug can't be in more than one mab list, and should stay only in the older active mab list, in this case the mab4.3 list.

so I'm removing it from mab4.2 and mab4.4 list.
Comment 15 Robinson Tryon (qubit) 2014-12-07 19:06:57 UTC
(In reply to tommy27 from comment #14)
> thanks Robinson for confirmation, however MAB rules say that a bug can't be
> in more than one mab list, and should stay only in the older active mab
> list

I know that the wiki says that, but I think that we should revisit the policy -- I was actually just mulling the situation on IRC.

Perhaps the MAB tag can be one bug, and the versions can be a separate tag in the Whiteboard. I'll bring up something on the QA list.
Comment 16 Jacobo Aragunde Pérez 2015-04-07 11:42:20 UTC
bc87fae0fc661b44769d71e41a0e8ce3dac3e857 is the first bad commit
commit bc87fae0fc661b44769d71e41a0e8ce3dac3e857
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Tue Apr 24 23:20:22 2012 +0200

    source-hash-f176c9ba7be7f3051a52b9f57b56124038c0cfd6
    
    commit f176c9ba7be7f3051a52b9f57b56124038c0cfd6
    Author:     Luboš Luňák <l.lunak@suse.cz>
    AuthorDate: Mon Dec 12 18:11:17 2011 +0100
    Commit:     Luboš Luňák <l.lunak@suse.cz>
    CommitDate: Mon Dec 12 19:01:44 2011 +0100
    
        fix docx hyperlink writing
    
        This is a rewrite of the fix for fdo#35826, needed for writing
        the document from bnc#706138 as docx. The sequence there is
        startURL(), runText(), endRun(), endUrl(), startUrl(), runText(), endUrl(), endRun(),
        so by the second endRun(), it is needed to close both the previous
        and current hyperlink run.

:100644 100644 667b7a2b3aaad36686a048ec622be1fd26616060 3eaeee61bd5fa0f3d8f6c9b6ec3f463dc9d494f5 M	ccache.log
:100644 100644 1229c909f7bed7dde1f0393b90c984eabbab9f2c 55db144259b3df131a412f6be8fa35e33e2f60ec M	commitmsg
:100644 100644 2f6c623f4e5c5965e70543edbf39d6fd3091061a 7a0c14b66a0e1587b4149debbdbb7c2418a98b73 M	dev-install.log
:100644 100644 f90ce629cb38af243d7f4fca65cb21f7a05485cc 32241ae1bc69be7d0705c82c8242315fb6eca750 M	make.log
:040000 040000 b0d767299d9ff3967b6f134deee3e46b45305f21 2e711a87a2be36d3183b7c70566dd576fb20799c M	opt

$ git bisect log
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327
# bad: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4
git bisect bad 369369915d3582924b3d01c9b01167268ed38f3b
# good: [351622aec2dff3cc3bbbb020ad0097c4322d2a21] source-hash-2c4537471c932b65e6f72e41881b505c4bbad12c
git bisect good 351622aec2dff3cc3bbbb020ad0097c4322d2a21
# bad: [378efb6e51212a05d1bd4b85c916eec5753c1744] source-hash-d453788ac0476cc02b929b0907718ca771d6d956
git bisect bad 378efb6e51212a05d1bd4b85c916eec5753c1744
# bad: [1a3c4b54a8782fe0f4bdba221e87012a92e4d323] source-hash-a330f38093e2643a26239557050561afae9ff23d
git bisect bad 1a3c4b54a8782fe0f4bdba221e87012a92e4d323
# good: [cf86b7f14a98d2d81a5cd93507acb35ff6775d8b] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5
git bisect good cf86b7f14a98d2d81a5cd93507acb35ff6775d8b
# bad: [bc87fae0fc661b44769d71e41a0e8ce3dac3e857] source-hash-f176c9ba7be7f3051a52b9f57b56124038c0cfd6
git bisect bad bc87fae0fc661b44769d71e41a0e8ce3dac3e857
# good: [0641af017cb9ec5ecca3eb879dded60fadf3ac78] source-hash-a1b970a10e00b34ab6d8608cb02247b8f0195573
git bisect good 0641af017cb9ec5ecca3eb879dded60fadf3ac78
# first bad commit: [bc87fae0fc661b44769d71e41a0e8ce3dac3e857] source-hash-f176c9ba7be7f3051a52b9f57b56124038c0cfd6
Comment 17 Jacobo Aragunde Pérez 2015-04-07 11:44:46 UTC
The output of the bibisect does not make sense to me, the pointed commit seems totally unrelated with this problem; in fact, that commit only affects Writer code when this problem happens in Calc.
Comment 18 Matthew Francis 2015-04-21 22:40:01 UTC
@Jacobo:

The result from bibisect 43all refers to a range rather than a single commit, so the culprit is between the source commits mentioned in bc87fae0fc and bc87fae0fc~1
Comment 19 Matthew Francis 2015-04-21 22:43:21 UTC
This began at the below commit.
Adding Cc: to nopower@novell.com; Any chance you could take a look at this? Thanks

commit c7551439a9ff4073a0b652329357be46d07b2c91
Author: Noel Power <noel.power@novell.com>
Date:   Sun Dec 11 16:40:52 2011 +0000

    fix autocorrection sync problem with input/formulabar
    
    also,
    * make the GetEditView explicitly create EditEngine/EditView *always*
    * remove the bogus GetLine method
    * reset NotifyHdl when stopping the edit engine
Comment 20 Matthew Francis 2015-04-21 22:48:28 UTC
Specifically it's the part of the above relating to inputwin.cxx/hxx

Unfortunately some intervening change means that simply reverting this doesn't seem to fix the problem - possibly the one which removed the argument from InitEditEngine() (i.e. 4b6e0d42d72f8d2f5a18a0e0af595d884d96f552)
Comment 21 Matthew Francis 2015-04-22 00:13:54 UTC
Each time F2 is pressed I see two calls to

accessibility::AccessibleTextHelper_Impl::addAccessibleEventListener

while when Esc is pressed there is only one call to

accessibility::AccessibleTextHelper_Impl::removeAccessibleEventListener


The two add calls are specifically

#0  accessibility::AccessibleTextHelper_Impl::addAccessibleEventListener (this=0x1ac5e60, xListener=uno::Reference to (AtkListener *) 0x7fffc81142e0) at /home/asbel/Development/LibreOffice/core/svx/source/accessibility/AccessibleTextHelper.cxx:1583

#0  accessibility::AccessibleTextHelper_Impl::addAccessibleEventListener (this=0x1c1a720, xListener=uno::Reference to (DocumentFocusListener *) 0x7fffc884b940) at /home/asbel/Development/LibreOffice/core/svx/source/accessibility/AccessibleTextHelper.cxx:1583


while the single remove call is

#0  accessibility::AccessibleTextHelper_Impl::removeAccessibleEventListener (this=0x1c1a720, xListener=uno::Reference to (DocumentFocusListener *) 0x7fffc884b940) at /home/asbel/Development/LibreOffice/core/svx/source/accessibility/AccessibleTextHelper.cxx:1590


so if I understand correctly we are endlessly accumulating listener references to AtkListener*s without ever removing them
Comment 22 Jacobo Aragunde Pérez 2015-04-22 07:08:35 UTC
Thanks for the code pointers, I will try to get my hands on the code next week and maybe check bug #71435 at the same time.
Comment 23 Michael Meeks 2015-10-16 08:50:34 UTC
Matthew Francis has (kindly) located the two places where we add the accessible listeners; to fix this we should first reproduce the problem; second put a couple of breakpoints into:

addAccessibleEventListener and removeAccessibleEventListener

get a full (with symbols) backtrace from each of these.

Clearly one of those code-paths is not going on to call removeAccessibleEventListener - hence the problem =)

It'd be great to have help to fix this for the impaired.

Thanks !
Comment 24 Niklas Johansson 2015-11-05 16:03:24 UTC
Created attachment 120291 [details]
Backtrace - addAccessibleEventListener (AtkListener)

I'll add the backtraces one for each breakpoint mentioned in comment 21.
Comment 25 Niklas Johansson 2015-11-05 16:04:04 UTC
Created attachment 120292 [details]
Backtrace - addAccessibleEventListener (DocumentFocusListener)
Comment 26 Niklas Johansson 2015-11-05 16:05:01 UTC
Created attachment 120293 [details]
Backtrace - removeAccessibleEventListener (DocumentFocusListener)
Comment 27 Michael Meeks 2015-11-05 17:49:54 UTC
The AtkListener: https://bug-attachments.documentfoundation.org/attachment.cgi?id=120291 is leaked through this trace as you see; thanks for that.

It seems like the problem is the AtkObjectWrapper we have holds this context:

    css::uno::Reference<css::accessibility::XAccessibleContext> mpContext;

We then connect an AtkListener to another interface on this Context:

AtkObject *
atk_object_wrapper_new( const ::com::sun::star::uno::Reference< ::com::sun::star::accessibility::XAccessible >& rxAccessible,
                        AtkObject* parent )
...
        // Attach a listener to the UNO object if it's not TRANSIENT
...
            uno::Reference< accessibility::XAccessibleEventBroadcaster > xBroadcaster(xContext, uno::UNO_QUERY);
            if( xBroadcaster.is() )
                xBroadcaster->addAccessibleEventListener( static_cast< accessibility::XAccessibleEventListener * > ( new AtkListener(pWrap) ) );

So - now we have the object that we hold a reference on - that holds a reference to the new AtkListener UNO object - which (in turn) holds a GObject reference to us (ie. the pWrap AtkObjectWrapper).

I -imagine- that therein lines the reference loop & the problem =)
Comment 28 Michael Meeks 2015-11-05 17:49:54 UTC
The AtkListener: https://bug-attachments.documentfoundation.org/attachment.cgi?id=120291 is leaked through this trace as you see; thanks for that.

It seems like the problem is the AtkObjectWrapper we have holds this context:

    css::uno::Reference<css::accessibility::XAccessibleContext> mpContext;

We then connect an AtkListener to another interface on this Context:

AtkObject *
atk_object_wrapper_new( const ::com::sun::star::uno::Reference< ::com::sun::star::accessibility::XAccessible >& rxAccessible,
                        AtkObject* parent )
...
        // Attach a listener to the UNO object if it's not TRANSIENT
...
            uno::Reference< accessibility::XAccessibleEventBroadcaster > xBroadcaster(xContext, uno::UNO_QUERY);
            if( xBroadcaster.is() )
                xBroadcaster->addAccessibleEventListener( static_cast< accessibility::XAccessibleEventListener * > ( new AtkListener(pWrap) ) );

So - now we have the object that we hold a reference on - that holds a reference to the new AtkListener UNO object - which (in turn) holds a GObject reference to us (ie. the pWrap AtkObjectWrapper).

I -imagine- that therein lines the reference loop & the problem =)
Comment 29 Michael Meeks 2015-11-05 17:53:32 UTC
I imagine that a patch a bit like:

Storing this guy:

            uno::Reference< accessibility::XAccessibleEventBroadcaster > xBroadcaster(xContext, uno::UNO_QUERY);

On the Wrapper itself as an UNO reference (along with the AtkListener?)

And in the:

void atk_object_wrapper_dispose(AtkObjectWrapper* wrapper)

removing the event listener - -might- make this work nicely ;-)

Of course - not poked in the debugger to see whether that thing is disposed, and if so by whom etc. you'd hope that someone was disposing those things =)

Failign that - quite possibly the specific implementation of 

XAccessibleEventBroadcaster

in this case is not calling 'disposing' properly when the F2/Escape cycle happens; not sure ... =)
Comment 30 Robinson Tryon (qubit) 2015-12-14 00:48:14 UTC
Migrating Whiteboard tags to Keywords: (bibisected easyHack difficultyInteresting SkillCpp TopicCleanup)
[NinjaEdit]
Comment 31 Robinson Tryon (qubit) 2016-02-18 14:52:29 UTC
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
[NinjaEdit]
Comment 32 Alex ARNAUD 2016-05-04 14:33:50 UTC
Dear all,
I've done test and the problem is still present in version 5.1.2.

Best regards.
Comment 33 Eike Rathke 2016-08-11 15:05:45 UTC
The good news is, for LibreOffice 5.2 this is gone with the gtk3 backend.
The bad news is, it persists when using the gtk2 backend, i.e. for a gtk3 enabled build invoked with SAL_USE_VCLPLUGIN=gtk (note gtk instead of gtk2).
On the other hand that might provide a a hint to look at the gtk2 specific code and see if there's something obviously different from the gtk3 code.
Comment 34 Michael Meeks 2016-11-11 16:01:34 UTC
While my suggestion may make it an easy hack - I don't think its a great candidate =)
Comment 35 Kohei Yoshida 2016-11-13 16:53:36 UTC
I'm taking a cursory look at this now.
Comment 36 Kohei Yoshida 2016-11-13 17:09:12 UTC
Created attachment 128731 [details]
accessible-event listener adjusted for python3

I've slightly modified the original listener script to adopt to python3 & specify the Atspi version.
Comment 37 Commit Notification 2016-11-16 05:08:22 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e4e208fa2b0930be5a7cbbe2fab2ff2fe2c4a1ff

tdf#71409: properly remove itself from the context it listens.

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 38 Commit Notification 2016-11-18 13:55:10 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0bc023d55afcf373a3b6644545ce4bae1bb5ca47

fdo#71409: Prevent the a11y code from creating an edit view instance.

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 39 tommy27 2016-11-18 14:56:16 UTC
@Kohey
nice to see you hacking the LibO code again
Comment 40 Commit Notification 2016-11-22 13:18:59 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a0ef7474521413c8967559a635e6fdc0d88f1df6

tdf#71409: Use weak reference to avoid potential circular references.

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 41 Commit Notification 2016-11-22 13:19:18 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=87e040fd0f04307534920d0765af6d5878794a98

tdf#71409: Stop listening to objects going out-of-focus.

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 42 Kohei Yoshida 2016-11-23 01:08:16 UTC
I'll take it for now.
Comment 43 Commit Notification 2016-11-30 00:59:03 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9ba24ac54100a5af6ecdde479ebeb5c916e6fad2

tdf#71409: always create edit engine instance for the input window.

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 44 Kohei Yoshida 2016-11-30 01:05:28 UTC
So, this bug has exposed a number of distinct issues around the accessibility code, and with the last commit I think things are a little bit more under control.

I'll mark this bug resolved for now.  If you see any other issues please report it as a separate bug.
Comment 45 Kohei Yoshida 2016-12-04 16:54:09 UTC
Re-opening. My last fix is apparently crap.
Comment 46 Commit Notification 2016-12-06 03:24:44 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae923f941f70ebe99cc785076f3357015dd69003

tdf#71409: Let's not crash the function wizard dialog.

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 47 Kohei Yoshida 2016-12-06 03:25:30 UTC
Hopefully the last commit finally nails it...
Comment 48 Commit Notification 2017-03-01 00:09:05 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=10077a06d8f6d08f276f99024528ee31a57390a9

Revert my fix for tdf#71409, to hopefully fix tdf#104381.

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 49 Kohei Yoshida 2017-03-01 00:16:31 UTC
Had to revert this fix in order to fix Bug 104381.
Comment 50 Kohei Yoshida 2017-03-01 00:17:34 UTC
I'll pass the baton to someone who's more qualified & willing to tackle this one and/or any other a11y bugs.
Comment 51 Alex ARNAUD 2017-03-01 22:39:46 UTC
(In reply to Kohei Yoshida from comment #49)
> Had to revert this fix in order to fix Bug 104381.

Dear Kohei,

I've tested the new alpha build on Debian 8.7 and the revert sounds good to me.

Due to the importance of this bug, could you also revert your commits on the 5.3 branch?

Best regards.
Comment 52 Kohei Yoshida 2017-03-08 02:02:42 UTC
(In reply to Alex ARNAUD from comment #51)
> (In reply to Kohei Yoshida from comment #49)
> > Had to revert this fix in order to fix Bug 104381.
> 
> Dear Kohei,
> 
> I've tested the new alpha build on Debian 8.7 and the revert sounds good to
> me.
> 
> Due to the importance of this bug, could you also revert your commits on the
> 5.3 branch?

It's there, waiting to be reviewed.

https://gerrit.libreoffice.org/#/c/34732/
Comment 53 Commit Notification 2017-03-08 09:11:32 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6f36ee01ab3d7934880bfd8b5d337288dcbf62c7&h=libreoffice-5-3

Revert my fix for tdf#71409, to hopefully fix tdf#104381.

It will be available in 5.3.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 54 am_dxer 2017-05-29 19:13:23 UTC
*** Bug 108053 has been marked as a duplicate of this bug. ***
Comment 55 am_dxer 2017-05-30 12:27:38 UTC
It was mentioned that this doesn't occur in the GTK3 version of LibreOffice. When I tested with master yesterday, I was able to repro in both the GTK3 and GTK2 versions. I will try to bisect sometime this week to to determine when the regression was introduced into the GTK3 version.
Comment 56 am_dxer 2017-06-16 21:00:03 UTC
I bisected the GTK3 regression in the bibisect-5.3 repository.
It would be very helpful if someone could try to fix this as it currently prevents screen reader users from using Calc on Linux.


# bad: [1bfd8dda84f0dd2c5662b64f382637d75b8bf227] source sha:6238f71ddbdc766e733b1c808a4fa7d66f7bde87
# good: [33e60eae04c889baf52713a73dc9944015408914] source sha:5b168b3fa568e48e795234dc5fa454bf24c9805e
git bisect start 'origin/master' 'oldest'
# bad: [964789dfd0674f0447da363a8c52114097796fa3] source sha:e473e0e1b9bc354d53908cb0ca84db06c3051fe2
git bisect bad 964789dfd0674f0447da363a8c52114097796fa3
# good: [e076e507d65a9ac4e63569e22b7384a0eb67c5a0] source sha:8550366138d576123b9e66a1a7915a04026d79cd
git bisect good e076e507d65a9ac4e63569e22b7384a0eb67c5a0
# skip: [d52331d7197320082f2a7c0454b23559937e2e78] source sha:66a117c8473cfa8181e139e406470428edffd32c
git bisect skip d52331d7197320082f2a7c0454b23559937e2e78
# bad: [e0ff56e8f13715625a8b478460d1fd70a137d9d1] source sha:8bb1726007f641dff2aa17d2e79a089e09fd9770
git bisect bad e0ff56e8f13715625a8b478460d1fd70a137d9d1
# good: [a4f5801d68e3d73326ebdc2a1baebbdd4d79d3de] source sha:e646286c306fc92867641cc399f640b69c0ec62a
git bisect good a4f5801d68e3d73326ebdc2a1baebbdd4d79d3de
# bad: [0b33f68e36cd7c515a0a4be5f96f02a111767ebe] source sha:9dc3356f1499a2b90078be86ca7470eb2e96aba8
git bisect bad 0b33f68e36cd7c515a0a4be5f96f02a111767ebe
# good: [76ee145a0b29f73225f917adb7aef67ca26b6042] source sha:3c425926d48e513937ad727a56ab7744ca379e63
git bisect good 76ee145a0b29f73225f917adb7aef67ca26b6042
# bad: [0f300ca4517ac7844e6de8bc4f01795a891ea731] source sha:0d8cc6e3a1e110ccdd260cbceb769f0a8083ae26
git bisect bad 0f300ca4517ac7844e6de8bc4f01795a891ea731
# good: [d4ab6329c8f2f36c70f03c1583217a58b3151877] source sha:35595869d19f052cb585c82a1a7e174debb944b0
git bisect good d4ab6329c8f2f36c70f03c1583217a58b3151877
# good: [6a47f2e47262e635c2c2bbe396db696c076aef3e] source sha:56823b52e50b6229265e92724732c123d1567e3c
git bisect good 6a47f2e47262e635c2c2bbe396db696c076aef3e
# good: [adbd9e1998483b1520b228543cde0580a857826e] source sha:9b47a8b21f87fa77d2d61ac4a2c2bbc7c0d67a19
git bisect good adbd9e1998483b1520b228543cde0580a857826e
# bad: [cc5dd64b38938f06aa02e717c11f6d4356309289] source sha:27328034f5e2644b4a0287532e762e87ea36c4a0
git bisect bad cc5dd64b38938f06aa02e717c11f6d4356309289
# good: [a71cb0b5f8cd2082bbf56fec1dfe70e487ae741f] source sha:b4f6abd4ba8c3a65216af3910a32cb1dc089ef5f
git bisect good a71cb0b5f8cd2082bbf56fec1dfe70e487ae741f
# good: [f1558b33d4e88087bae1e3344ea67bd47d5a8820] source sha:d7a0bc2a7eab58311f3925d0ce9b2b863188bfe8
git bisect good f1558b33d4e88087bae1e3344ea67bd47d5a8820
# first bad commit: [cc5dd64b38938f06aa02e717c11f6d4356309289] source sha:27328034f5e2644b4a0287532e762e87ea36c4a0
# good: [f1558b33d4e88087bae1e3344ea67bd47d5a8820] source sha:d7a0bc2a7eab58311f3925d0ce9b2b863188bfe8
git bisect good f1558b33d4e88087bae1e3344ea67bd47d5a8820
# first bad commit: [cc5dd64b38938f06aa02e717c11f6d4356309289] source sha:27328034f5e2644b4a0287532e762e87ea36c4a0
Comment 57 Alex ARNAUD 2017-06-19 12:52:54 UTC
Dear all,

Thanks to  am_dxer for the bibisect.

The commit that introduce the regression is this one : 

"commit 27328034f5e2644b4a0287532e762e87ea36c4a0
Author: Caolán McNamara <xxxx@xxxx>
Date:   Thu Jul 21 11:55:13 2016 +0100

    gtk3-a11y: our eventbox is inside a grid now
    
    Change-Id: Icb49d6274b09fb426ab6c0f9f67b7c71c4ef9a31"


@Caolán: could you tell us the goal of this commit ?

Best regards.
Comment 58 Caolán McNamara 2017-06-19 14:20:06 UTC
That bisect has unfortunately led you nowhere useful, before that commit a11y wasn't working at all under gtk3 so its various bugs were not seen.
Comment 59 am_dxer 2017-06-19 14:47:39 UTC
Can you explain what you mean by this. My about dialog says that GTK3 is being used. After this commit, calc gets slower and slower. Before this commit, it works correctly in the GTK3 version. The GTK2 version gets slower and slower before and after this commit if i manually select that version when running so it appears something different is happening when running in GTK3 mode.
Comment 60 am_dxer 2017-06-19 14:59:44 UTC
I am also sure that I am running in gTK3 mode because if I manually select GTK2 in this commit range, the program crashes with another error message when I try to type in cells. It is a gui dialog box with a message hat says "Text forwarder is invalid, object is defunct".
Comment 61 am_dxer 2017-06-19 15:18:34 UTC
I should make a correction here. I looked back at the About dialog and the VCL was actually not showing in that particular commit, however, I can still see the difference in behavior described in comment 60 when I use SAL_USE_VCLPLUGIN=gtk3 vs SAL_USE_VCLPLUGIN=gtk. It looks like the VCL being used was added to the about dialog in a later commit.
Comment 62 am_dxer 2017-06-21 23:23:41 UTC
I reverted commit 27328034f5e2644b4a0287532e762e87ea36c4a0 on the latest master branch of libreoffice today and built it. This fixes the bug for the GTK3 version of libreoffice. Orca no longer gets slower and slower as data is typed into cells.
Comment 63 am_dxer 2017-06-21 23:51:51 UTC
I tested with the GTK2 version and reverting this unfortunately does not fix that version. still, it would be great to at least have orca functioning with the GTK3 version again. Even if reverting this commit is not the correct course of action, I hope that this information can at least lead someone to what may be causing the issue.
Comment 64 am_dxer 2017-06-23 16:27:17 UTC
I just built LibreOffice without reverting the change in comment 57 to confirm that this still occurred in master. I am experiencing this issue in the GTK3 version. I am noticing  Orca only seems slow if moving between cells that contain different data. For example, if moving between two blank cells or two cells which have the same data, the slowness doesn't occur. The slowness only occurs when moving to a cell which contains different data from the current cell. Also, data must be entered into multiple cells and this gradually gets worse. If the commit in comment 57 is reverted on the master branch, I don't experience this issue.
@Caolán: could you have another look to see what might be going wrong here?
Comment 65 Alex ARNAUD 2017-06-24 16:07:10 UTC
(In reply to Caolán McNamara from comment #58)
> That bisect has unfortunately led you nowhere useful, before that commit
> a11y wasn't working at all under gtk3 so its various bugs were not seen.

Hello Caolan,

I've also built LibreOffice from master with and without the patch. I see no differences on the accessibility side.

Could you be more precise on what the commit should fixed ? If you have submitted a patch maybe someone ask you that or there is a related bug.

Best regards.
Comment 66 Alex ARNAUD 2017-06-24 18:05:41 UTC
(In reply to Alex ARNAUD from comment #65)
> I've also built LibreOffice from master with and without the patch. I see no
> differences on the accessibility side.

To be more precise : I'm GTK3 VCL, the issue describes is solved if I revert the commit describe in comment #57.
After testing Writer and Calc I see the regression but no improvements from the commit.

Best regards.
Comment 67 Caolán McNamara 2017-06-24 20:44:04 UTC
You have gone down the wrong path here, the bug here affects both the gtk2 and gtk3 backends (and presumably all other platforms) My gtk3 patch which you are focusing on in recent comments just brings the gtk3 plugin back into alignment with the gtk2 version because an intermediate widget for events was needed for gtk3 and the various listeners weren't updated to reflect that change so various a11y handlers weren't getting called.

Comments 55-66 don't relate to the underlying problem, just to a period where the problem was masked by the incomplete gtk3 implementation and so affects the gtk3 the same as gtk2 when that was corrected.

I don't know the exact nature of the specific underlying problem of the calc a11y input line, but it is not related to my global gtk3 a11y change.
Comment 68 Joanmarie Diggs 2017-06-24 21:09:59 UTC
(In reply to Caolán McNamara from comment #67)
> You have gone down the wrong path here, the bug here affects both the gtk2
> and gtk3 backends (and presumably all other platforms)

Yeah, as I stated in comment #3 -- back in 2013 -- you can reproduce it on the Mac.
Comment 69 am_dxer 2017-06-24 21:45:58 UTC
would there be anything wrong with reverting it until a correct fix can be worked out? At least it allows Orca users to use calc at the current moment with GTK3. in the current state, calc is totally unusable with orca after editing 15 or so cells.
Comment 70 Alex ARNAUD 2017-06-25 15:15:46 UTC
(In reply to Jacobo Aragunde Pérez from comment #22)
> Thanks for the code pointers, I will try to get my hands on the code next
> week and maybe check bug #71435 at the same time.

Hello Jacobo,

Are you still planning to work on this bug? 

Best regards.
Comment 71 Alex ARNAUD 2017-06-25 15:18:14 UTC
(In reply to Joanmarie Diggs from comment #68)
> (In reply to Caolán McNamara from comment #67)
> > You have gone down the wrong path here, the bug here affects both the gtk2
> > and gtk3 backends (and presumably all other platforms)
> 
> Yeah, as I stated in comment #3 -- back in 2013 -- you can reproduce it on
> the Mac.

OK, thank you very much for the clarification.

Best regards.
Comment 72 Jacobo Aragunde Pérez 2017-06-26 08:53:30 UTC
(In reply to Alex ARNAUD from comment #70)
> (In reply to Jacobo Aragunde Pérez from comment #22)
> > Thanks for the code pointers, I will try to get my hands on the code next
> > week and maybe check bug #71435 at the same time.
> 
> Hello Jacobo,
> 
> Are you still planning to work on this bug? 

Hi Alex,

I tried back in the day but was unable to fix it, now I don't have any time to book for it.  Sorry!
Comment 73 am_dxer 2017-06-26 11:21:17 UTC
I still vote for reverting the commit we've been talking about in comment 56. I understand that it is not correct but it does make Calc usable with Orca. It seems that this is a complicated issue that won't be solved for a while due to a lack of time. The problem is that right now, users like me who are totally blind cannot use Calc at all.
Comment 74 Alex ARNAUD 2017-06-26 12:51:05 UTC
(In reply to am_dxer from comment #73)
> I still vote for reverting the commit we've been talking about in comment
> 56. I understand that it is not correct but it does make Calc usable with
> Orca. It seems that this is a complicated issue that won't be solved for a
> while due to a lack of time. The problem is that right now, users like me
> who are totally blind cannot use Calc at all.

I agree with am_dxer. At this time on GNU/Linux, maybe also on macOS, Calc is not usable due to this issue so it is preferable to have initialization issues on GTK3 instead of a completely unusable program.

I understand the point of view of Caolan and Joanie but if no one can work on this issue how could we expect to use Calc with the GTK3 VCL ?

Best regards.
Comment 75 am_dxer 2017-06-26 16:11:22 UTC
(In reply to Alex ARNAUD from comment #74)
> (In reply to am_dxer from comment #73)
> > I still vote for reverting the commit we've been talking about in comment
> > 56. I understand that it is not correct but it does make Calc usable with
> > Orca. It seems that this is a complicated issue that won't be solved for a
> > while due to a lack of time. The problem is that right now, users like me
> > who are totally blind cannot use Calc at all.
> 
> I agree with am_dxer. At this time on GNU/Linux, maybe also on macOS, Calc
> is not usable due to this issue so it is preferable to have initialization
> issues on GTK3 instead of a completely unusable program.
> 
> I understand the point of view of Caolan and Joanie but if no one can work
> on this issue how could we expect to use Calc with the GTK3 VCL ?
> 
> Best regards.

Most blind people are using the GTK3 version of LibreOffice anyway since they are likely using Gnome or Mate. Even though this revert doesn't fix the Mac issue, blind people on that platform can just use Apples Numbers until this is resolved the proper way. We don't have an alternative on Linux.
Comment 76 David Hunt 2017-06-26 23:04:04 UTC
Using Libreoffice Calc, 5,3,4,2, and orca 3.24 Pre, as packaged in Arch Linux repository:
While doing data entry and editing, in the spreadsheet, Orca becomes progressively slower to give feedback on key presses, be they movements or alpha-numeric keys. Eventually, this slowdown gets to the point where the Orca and Calc combination is unusable.  Because of this persistent difficulty, I, as a blind person, cannot recommend, with high confidence, using this version of Libreoffice Calc and Orca screen reader.
Comment 77 am_dxer 2017-06-28 12:44:37 UTC
Hello,
I have now been running for a week with the commit in comment 56 above reverted and I am finding no accessibility issues caused by reverting.
@Caolán: I know that reverting this hides a bug deeper in the code and that reverting is not the proper long term solution but I might ask again if you would consider reverting this until we can find a proper fix. The problem is that right now, me and any other blind individuals can't use calc at all. Distros are already shipping with versions of calc that blind individuals can't use. Maybe a comment/fixme could be added to the code that the commit was reverted to work around an accessibility bug until a proper solution could be developed. Thanks in advance for your understanding.
Comment 78 am_dxer 2017-06-30 12:27:12 UTC
@Caolán: Is there a technical reason that makes you reluctant to revert this? I am still running and noticing no regressions from the above commit. Would really appreciate a revert on this one until a proper fix can be found.
Comment 79 Caolán McNamara 2017-07-05 15:26:55 UTC
Reverting my fix just in effect disables a major hunk of a11y features, and just for gtk3. You can see this is accerciser for example where with this hacked out it just reports "<dead>" for the contents of the main frame rather than the tree of widgets it reports otherwise. You might as well just specifically disable the input bar a11y support to get the same effect.
Comment 80 Dennis Francis 2017-07-25 09:18:13 UTC
I still see the issue in master, will try to figure out the problem.
Comment 81 Dennis Francis 2017-07-27 09:59:26 UTC
I made a fix attempt in vcl at https://gerrit.libreoffice.org/#/c/40479/, but has some problems as described in the commit message, although it seems to fix this bug.

Caolan, it would be really helpful if you can take a look at the patch and provide some hints :) Thanks !
Comment 82 Dennis Francis 2017-08-04 05:30:04 UTC
Updated the patch https://gerrit.libreoffice.org/40479 to work around the issue to make the change Calc specific. More details in the patch commit message.
Comment 83 Commit Notification 2017-08-07 07:59:09 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=561cae8e81913940e4af86901ec46a484669c597

tdf#71409: Pre-create sum/equal and ok/cancel buttons...

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 84 Dennis Francis 2017-08-08 05:21:57 UTC
Fixed in master, waiting for review in 5-4 branch.
Comment 85 Commit Notification 2017-08-11 12:04:12 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0aaa81b2760dde7e84c85b8caacc20552910ffe9&h=libreoffice-5-4

tdf#71409: Pre-create sum/equal and ok/cancel buttons...

It will be available in 5.4.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 86 Alex ARNAUD 2017-08-21 17:29:30 UTC
Dear all,

I confirm the resolution with LibreOfficeDev 6.0 (2017-08-21) on Debian 8.9.

Best regards.
Comment 87 am_dxer 2017-09-16 17:37:09 UTC
@Dennis: Thanks for fixing this. I tested and am confirming that this is fixed in the 5.4 branch.