Bug 71409 - Excessive duplicate accessible focused events for Calc input line [a11y]
Summary: Excessive duplicate accessible focused events for Calc input line [a11y]
Status: REOPENED
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: Not Assigned
QA Contact:
URL:
Whiteboard: target:5.4.0 target:5.3.2
Keywords: bibisected, bisected, regression
Depends on:
Blocks: a11y
  Show dependency treegraph
 
Reported: 2013-11-08 23:59 UTC by Joanmarie Diggs
Modified: 2017-03-08 09:11 UTC (History)
21 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.