Hi,
I'm working for CodeWeavers on a project that uses accessibility API's
(specifically at-spi 2) to manipulate text fields. I cannot publicly
disclose the exact nature of this project before its release, though
it may be possible to provide access to this project for selected
developers.
We're having some problems with selections in Writer that appear to be
bugs in Writer, which I've filed as bug 43390. Unfortunately, the bug
is rather confusing because I did not fully understand the issue until
after I had filed it. I have a detailed technical explanation and a
patch that I believe is correct in comment 2
(https://www.libreoffice.org/bugzilla/show_bug.cgi?id=43390#c2), but
for clarity here's a summary of the behavior I'm seeing without any
discussion of the causes:
* If one sets the selection in a Writer document using the
SetSelection method on the org.a11y.atspi.Text interface (which
libreoffice implements in the text_wrapper_set_selection function, in
vcl/unx/gtk/a11y/atktext.cxx), it appears to work correctly. However,
moving the cursor afterwards (by pressing an arrow key, for example),
does not kill the selection but only moves one end of it. I've found
that clicking around eventually gets it back to a somewhat normal
state, but it does not work immediately or following any pattern I've
been able to discern.
* If one clears the selection in a Writer document using the
RemoveSelection method, then sets the caret using SetCaretOffset, the
result is a selection from the beginning of the line to the given
caret offset.
* Setting the caret using SetCaretOffset while a selection is in place
does not kill the selection. I'm not convinced that it should, which
is why I'm calling RemoveSelection first. But since this doesn't do
what I want either, it's not a suitable work-around.
I would like to get my patch (or some other fix if mine turns out to
be wrong) into libreoffice and, if possible, cherry-picked into
libreoffice 3.5 so that the project I'm working on can function
properly with Writer in Ubuntu 12.04 without requiring a special
build.
I believe the fix to be low risk (as accessibility methods
manipulating the selection/cursor seem to be rarely used, to my
knowledge they have never worked correctly, and my patch only has an
effect when those methods are called) and low importance (to most
people) for the same reasons. However, getting it into 3.5 is very
important to us.
I do not currently have a test case. Unfortunately, accerciser is not
able to call selection methods, apparently because of bugs in the
python library it uses to interact with at-spi (?!). I hope to have a
small C program written that can reproduce this soon.
diff --git a/sw/source/core/access/acccontext.cxx b/sw/source/core/access/acccontext.cxx
index 8c38ba1..2949c1e 100644
--- a/sw/source/core/access/acccontext.cxx
+++ b/sw/source/core/access/acccontext.cxx
@@ -40,6 +40,7 @@
#include <viewsh.hxx>
#include <crsrsh.hxx>
#include <fesh.hxx>
+#include <wrtsh.hxx>
#include <txtfrm.hxx>
#include <ndtxt.hxx>
#include <pagefrm.hxx>
@@ -1359,6 +1360,10 @@ sal_Bool SwAccessibleContext::Select( SwPaM *pPaM, SdrObject *pObj,
if( pFEShell )
pFEShell->FinishOLEObj();
+ SwWrtShell* pWrtShell = pCrsrShell->ISA( SwWrtShell )
+ ? static_cast<SwWrtShell*>( pCrsrShell )
+ : 0;
+
sal_Bool bRet = sal_False;
if( pObj )
{
@@ -1383,7 +1388,17 @@ sal_Bool SwAccessibleContext::Select( SwPaM *pPaM, SdrObject *pObj,
bCallShowCrsr = sal_True;
}
pCrsrShell->KillPams();
+ if( pWrtShell && pPaM->HasMark() )
+ // We have to do this or SwWrtShell can't figure out that it needs
+ // to kill the selection later, when the user moves the cursor.
+ pWrtShell->SttSelect();
pCrsrShell->SetSelection( *pPaM );
+ if( pPaM->HasMark() && *pPaM->GetPoint() == *pPaM->GetMark())
+ // Setting a "Selection" that starts and ends at the same spot
+ // should remove the selection rather than create an empty one, so
+ // that we get defined behavior if accessibility sets the cursor
+ // later.
+ pCrsrShell->ClearMark();
if( bCallShowCrsr )
pCrsrShell->ShowCrsr();
bRet = sal_True;
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
