Skip to content

Chrome: "list" is reported on every line of a list in rich text editors #7562

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jcsteh opened this issue Sep 4, 2017 · 3 comments · Fixed by #11605
Closed

Chrome: "list" is reported on every line of a list in rich text editors #7562

jcsteh opened this issue Sep 4, 2017 · 3 comments · Fixed by #11605
Labels
app/chrome GoogleWork issue-tracking/crbug This issue is also tracked by another issue tracker: 'crbug' p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority z goodForNewDev (archived)
Milestone

Comments

@jcsteh
Copy link
Contributor

jcsteh commented Sep 4, 2017

Steps to reproduce:

  1. Open this URL in Chrome:
    data:text/html,<div contentEditable="true" role="textbox" aria-multiline="true">Before<ul><li>a</li><li>b</li></ul>After</div>
  2. Focus the text box and ensure you are in focus mode.
  3. Press control+home.
  4. Read through the content line by line using the down arrow key.

Expected behavior:

Before
list  bullet  a
bullet  b
out of list  After

Actual behavior:

Before
list  bullet  a
list  bullet  b
After

Note: Whether you hear "bullet" depends on your symbol level; I have mine set to "all".

System configuration:

NVDA version: next-14373,6bbe5915
NVDA Installed or portable: installed
Windows version: Windows 10 Version 1703 (OS Build 16251.0)
Name and version of other software in use when reproducing the issue: Chrome Version 62.0.3201.2 (Official Build) canary (64-bit)

Technical info:

This happens because a contentEditable list (the ul tag) does not get the read-only state. Lists and list boxes both get the same role (list), but they're normally differentiated by the read-only state; a <ul> has read-only, whereas a <select size="2"> doesn't. However, in this case, I can kinda understand why Chrome doesn't set read-only; after all, it does have the editable state.

I think we should probably just tweak TextInfo.getPresentationCategory to treat editable liss as being containers; i.e. allow for the editable state as well as the read-only state in the rule for PRESCAT_CONTAINER. Alternatively, we could file a bug against Chrome requesting this get fixed on their side.

P2 because this is quite annoying when dealing with rich text editors in Chrome, including the Gmail composer.

@jcsteh jcsteh added app/chrome p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority GoogleWork z goodForNewDev (archived) labels Sep 4, 2017
@awalvie
Copy link
Contributor

awalvie commented Mar 17, 2019

I was trying to understand the getPresentationCategory function and was wondering what this is currently returning among

PRESCAT_LAYOUT
PRESCAT_CONTAINER
PRESCAT_CELL
PRESCAT_SINGLELINE
PRESCAT_MARKER

when we are focusing on a list as pointed out in the issue.

@awalvie
Copy link
Contributor

awalvie commented Mar 17, 2019

Nevermind I think it is returning SINGLELINE

@ObjectInSpace
Copy link

Filed https://crbug.com/1087551 to track this.

@feerrenrut feerrenrut added the issue-tracking/crbug This issue is also tracked by another issue tracker: 'crbug' label Jun 11, 2020
michaelDCurran added a commit that referenced this issue Sep 14, 2020
michaelDCurran added a commit that referenced this issue Sep 16, 2020
…contenteditables (#11605)

* Ensure that ul, dl and ol tags in Chrome get the readonly state so that 'list' is not announced on every line when in a contenteditable.

* Add system test for #7562

* Fix linting issues

* Improve docstring

* Chrome system tests: The Before and After markers are now paragraphs rather than buttons. They no longer need to be focusable as we use f6 not tab.

* System test NVDA configs: disable browse mode passThroughAudioIndication, which then means that switching between browse and focus modes produces a spoken string we can check for.

* System test i7562: explicitly force focus mode at the beginning to ensure we don't accidentally test in browse mode.

* Fix linting issues

* Update what's new
@nvaccessAuto nvaccessAuto added this to the 2020.4 milestone Sep 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
app/chrome GoogleWork issue-tracking/crbug This issue is also tracked by another issue tracker: 'crbug' p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority z goodForNewDev (archived)
Projects
None yet
5 participants