Bug Hunting Session
Bug 106718 - In read-only text documents, when selection cursor enabled, only arrows keys allow to navigate through documents
Summary: In read-only text documents, when selection cursor enabled, only arrows keys ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.6.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks: a11y Read-Only
  Show dependency treegraph
 
Reported: 2017-03-23 09:53 UTC by Alex ARNAUD
Modified: 2019-08-04 05:49 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex ARNAUD 2017-03-23 09:53:13 UTC
Description:
Dear all,

I'm a partially sighted person, I read documents with keyboard shortcuts. I've checked in options "accessibility" the box "use text selection cursor in
read-only text documents" to be able to navigate through documents with the
keyboard because I can't use the mouse.

I can use arrows keys but others useful accelerators for a blind person don't work.
For example origin/end or page up/page down are not usable.

Steps to Reproduce:
A simple use case is :
I use a screen reader to read my document so I use speech synthesizer to listen the content of each line. If I want to verify a word I move
between words with ctrl+right to find the word I want to check and after
that if I want to check a word in the beginning of a line i would like
to be able to do origin.

Actual Results:  
It takes more time to use a computer when you
are blind (due to the use of the keyboard-only) so we should be able to
be more efficient as possible with the keyboard.

Expected Results:
It should be possible to use all keyboard accelerators even if in read-only document. 


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Comment 1 Julien Nabet 2017-03-23 10:44:48 UTC
Which LO version do you use?
FYI, last stable one is 5.2.6 and there's the brand new version 5.3.1.

Also, just to be sure to have well understood, the problem only appears with read-document only?
Comment 2 Alex ARNAUD 2017-03-24 08:00:12 UTC
(In reply to Julien Nabet from comment #1)
> Which LO version do you use?
> FYI, last stable one is 5.2.6 and there's the brand new version 5.3.1.

I use LibreOfficeDev 5.4 and LibreOffice 4.2.6 (VCL: GTK2) which have the same issue.

> Also, just to be sure to have well understood, the problem only appears with
> read-document only?

Yes, it's just in read-only documents.
Comment 3 Julien Nabet 2017-03-24 08:02:29 UTC
Thank you for your feedback.
Since I don't have more questions, I'll put it back to UNCONFIRMED.
Comment 4 Alex ARNAUD 2017-03-24 08:56:33 UTC
(In reply to Julien Nabet from comment #3)
> Thank you for your feedback.
> Since I don't have more questions, I'll put it back to UNCONFIRMED.

I've checked, the issue also appears on Windows 7.

Best regards.
Comment 5 V Stuart Foote 2017-03-24 13:07:02 UTC
Confirmed.

From Tools -> Options -> Accessibility:
"Support assistive technology tools" and
"Use text selection cursor in read-only text documents"
options both checked active an ODF Writer .ODT document with Read-only property set by OS and opened in Writer read-only (i.e. showing the "This document is open in read-only mode" warning bar)

But of the shortcuts provided [1][2], just these shortcut keys are not correct
1. Home -> Position text cursor to beginning of current line
2. End -> Position text cursor to end of current line

There is an implementation error in Read-only mode as the <Ctrl>+ (to position) and <Ctrl>+<Shift>+ (to position & select) and <Shift>+ (to select current line) shortcuts for these keys functioned as expected with read-only document open and text cursor enabled.

Taken out of Read-only mode, i.e. enable editing with the 
"Edit Document" button action, and the correct movement of the End and Home key is restored. 

The PgDn and PgUp scroll the screen, but they do not reposition text cursor so there is no focus event for the AT to sound.  Not sure that is incorrect, but it makes the PgDn/PgUp keys pretty useless to AT.


=-ref-=
[1] https://help.libreoffice.org/Writer/Shortcut_Keys_for_Writer
[2] https://help.libreoffice.org/Writer/Navigating_and_Selecting_With_the_Keyboard


=-tested on-=

On Windows 10 Pro 64-bit en-US with NVDA 2017.1

Version: 5.4.0.0.alpha0+
Build ID: 522e9c65faef684a22151ddf009a5a192838b522
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-03-24_00:32:45
Locale: en-US (en_US); Calc: CL
Comment 6 QA Administrators 2018-07-02 02:35:12 UTC Comment hidden (obsolete)
Comment 7 Peter Vágner 2018-08-03 09:42:03 UTC
Retested this both on Linux and on Windows with the following results:
Home and end arrow keys alone (i.e. moving to the begining / end of a line) don't work in read only documents. When pressing shift+home or shift+end I can select to the begining / end of a line and orca reports to the fact.
Page up / page down keys in read only documents don't move the caret. And when pressing shift+page up / shift+page down nothing happens either.
ctrl+left and ctrl+right move by word and orca reports to the fact. The same goes in combination with the shift key i.e. shift+ctrl+left and shift+ctrl+right manipulate the selection by word.
ctrl+home and ctrl+end move to the begining / end of a section or the document depending of the context. shift+ctrl+home and shift+ctrl+end correctly select to the begining / to the end of a document.
All four arrow keys also their combination with shift key to manipulate selection are working fine.
Home and key have overridden their behaviour for tables, however when using home / end keys the same thing applies home / end keys alone don't work inside tables but in combination with ctrl and / or shift they are working inside tables as well.


Therefore I would say pageup and page down keys are broken no mather which modifiers are being pressed with them and home and end keys are only broken when being pressed alone.

Libreoffice version as reported in the Help -> About...
Version: 6.0.5.2
Build ID: 6.0.5-1
CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; 
Locale: en-US (en_US); Calc: group

Version: 6.0.6.2 (x64)
Build ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77
CPU threads: 4; OS:Windows 10.0; UI render: GL;
Locale: sk-SK (sk_SK); Calc: CL
Comment 8 QA Administrators 2019-08-04 05:49:30 UTC
Dear Alex ARNAUD,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug