Bug 35939 - ACCESSIBILITY: With LibreOffice Writer, the Windows7 Magnifier doesn't follow the insertion point
Summary: ACCESSIBILITY: With LibreOffice Writer, the Windows7 Magnifier doesn't follow...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Windows (All)
: medium enhancement
Assignee: Not Assigned
Keywords: accessibility
Depends on:
Blocks: a11y-Windows
  Show dependency treegraph
Reported: 2011-04-03 14:45 UTC by BSC
Modified: 2023-07-12 13:12 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Magnifier follows text insertion point, but only in Win 7 (681.70 KB, video/webm)
2020-05-31 20:36 UTC, Mike

Note You need to log in before you can comment on or make changes to this bug.
Description BSC 2011-04-03 14:45:42 UTC
The Windows7 Magnifier allow to magnify a part of the screen. An option allows the magnifier to automatically follow the insertion point.
The magnifier follows perfectly the insertion point when using most of software applications (Wordpad, Notepad, Microsoft Word, Notepad++ , Thunderbird, Firefox.

But NOT with LibreOffice Writer !!!! With LibreOffice, the magnifier follows only the mouse pointer.

This problem makes LibreOffice not usable for persons with visual impairment.

Seen on Windows7 and on Windows Vista, both with LibreOffice 3.3.2
Comment 1 Jan Holesovsky 2011-04-07 11:22:04 UTC
Please, do you know where is a description of the API that makes this possible?  I suppose the application has to let the system know where exactly is the cursor...
Comment 2 Bas Cancrinus 2011-11-04 10:08:57 UTC
Still seeing this with LibO 3.3.3 (OOO330m19 (Build:301)) on Windows 7 (X64). If there is anything that I can do or sort out, please let me know! This issue is blocking me from switching to LibO. Thanks!!
Comment 3 Björn Michaelsen 2011-12-23 11:47:36 UTC Comment hidden (obsolete)
Comment 4 BSC 2011-12-23 13:00:49 UTC
The problem is still here with LibreOffice 3.5.0 Beta 1 on Windows Vista
Comment 5 Björn Michaelsen 2011-12-23 14:58:59 UTC
NEW, unassigned bug: replace "infoprovider" with move to state "NEEDINFO".
Comment 6 Björn Michaelsen 2011-12-23 17:02:34 UTC
needinfo keyword redundant by needinfo status.
Comment 7 sasha.libreoffice 2012-02-16 04:24:35 UTC
@ Tor
Windows specific problem. Please, take look at this when have time
Comment 8 Florian Reisinger 2012-08-14 14:00:40 UTC Comment hidden (obsolete)
Comment 9 Florian Reisinger 2012-08-14 14:01:47 UTC Comment hidden (obsolete)
Comment 10 Florian Reisinger 2012-08-14 14:06:29 UTC Comment hidden (obsolete)
Comment 11 Florian Reisinger 2012-08-14 14:08:31 UTC Comment hidden (obsolete)
Comment 12 Bas Cancrinus 2012-09-28 11:39:49 UTC
Still seeing this with LibO (Build-id: e29a214) on Windows 7 (X64). If there is anything that I can do or sort out, please let me know! This issue is blocking me from switching to LibO due to my dependence on low vision aids. Thanks!!
Comment 13 Bas Cancrinus 2012-09-28 13:44:55 UTC
I have taken the following additional steps, but that didn't help:

1. Downloaded and installed Oracle JRE 1.7.0_07 (32 bit) from http://java.com

2. Enabled the Java Access Bridge following: http://docs.oracle.com/javase/7/docs/technotes/guides/access/enable_and_test.html

3. Added and selected the new JRE in LibO: Options > Java

4. Enabled assistive technology support in LibO: Options > Accessibliity

5. Restarted LibO.

Any other suggestions?
Comment 14 V Stuart Foote 2013-02-13 15:25:00 UTC
Windows 7 "Ease of Access" Magnifier feature is a Microsoft UI Automation dependent Assistive Technology with Aero dependencies for Full Screen & Lens modes that can only follow the mouse input or respond to cursor controlled positioning.

Tracking keyboard focus or text insertion point options are implemented only in the Magnifier's Docked mode.

It is a very helpful AT implementation, but Microsoft UI Automation can not follow Java Accessibility API focus events so existing mapping of UNO Accessibility API bridge events via Java Access Bridge (JAB) is not supported by Magnifier.

As a native Windows bridge is implemented with IAccessibile2, availibility of  	IAccessibleEditableText should expose position information to UI Automation for Magnifier.

Setting as Enhancement that should resolve with work on IAccessibile2 bug 39956
Comment 15 Christophe Strobbe 2013-08-07 12:04:22 UTC
The issue is still present in I think V. Stuart Foote is right when he says that it is related to the Java Accessibility API and that IAccessible2 needs to be implemented before this issue can be fixed. (Windows 7 Magnifier also fails to follow the text insertion point in NetBeans, which AFAIK, also implements the Java Accessibility API.)
Should bug 39956 be marked as a blocker for this one?

Anyway, a description of steps to reproduce the issue is missing.

1. Start the Windows 7 Magnifier (press the Windows key and type "Magnifier").
2. In the Magnifier options, uncheck "Follow the mouse pointer" and "Follow the keyboard focus" but make sure that "Have Magnifier follow the text insertion point" is checked.
3. Create, e.g., a Writer document and start typing text. Notice that the caret in the Magnifier window does not stay in the middle but eventually moves out of that Window. (Compare this behaviour with e.g. Notepad or a comment field on a webpage displayed in Firefox.)
4. In the Magnifier options, "Follow the keyboard focus" and notice that the behaviour does not improve.

Desired behaviour: the caret remains in the middle of the (docked) Magnifier window; compare with behaviour in e.g. Notepad.

As mentioned before, this test needs to be repeated once the IAccessible2 code has replaced the Java Accessibility API.
Comment 16 Christophe Strobbe 2013-08-07 12:14:11 UTC
To track the corresponding Apache OpenOffice issue: https://issues.apache.org/ooo/show_bug.cgi?id=117740
Comment 17 Joel Madero 2014-11-04 03:13:31 UTC
Looks like this was confirmed as an enhancement request. Moving to NEW as REOPENED is incorrect status.
Comment 18 Mike 2020-05-30 21:30:58 UTC
Seems fixed!

I use Win 7 with the final patch and

Version: (x64)
Build ID: 94c217984e456196047ce41096d4a6f05bf66382
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: threaded
Comment 19 BSC 2020-05-31 14:52:55 UTC
No, it doesn't seem fixed.
Tried today with Windows10 1909 64bits and LibreOffice
The magnifier still doesn't follow the insertion point.
Comment 20 BSC 2020-05-31 15:26:30 UTC
No, it doesn't seem fixed with LibreOffice 7.0.0 too...
Tried today with Windows10 1909 64bits and LibreOffice 7.0.0 beta1 X86
The magnifier still doesn't follow the insertion point.
Comment 21 Mike 2020-05-31 20:36:16 UTC
Created attachment 161479 [details]
Magnifier follows text insertion point, but only in Win 7
Comment 22 Mike 2020-05-31 20:37:37 UTC
You're correct, it does not work with Win 10. I should have tested it before with Win 10. Because the original report referred to Win 7 I only tested it with my VM, which has Win 7.

But the magnifier following the text insert position DOES work in Win 7. Really, no kidding! I attached a video I made with VBox.
Comment 23 BSC 2020-05-31 20:42:32 UTC
Windows10 didn't exist 9 years ago, when I posted the initial report...
Comment 24 shara hall 2022-09-08 02:03:27 UTC Comment hidden (spam)
Comment 25 rock martin 2023-07-12 11:11:48 UTC Comment hidden (spam)