New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 728453 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-10-01
OS: Mac
Pri: 3
Type: Bug
Team-Accessibility



Sign in to add a comment

Chrome is using copying to implement Speak selected text

Project Member Reported by chaoshen@google.com, Jun 1 2017

Issue description

Chrome Version       : 58.0.3029.110 (64-bit)
URLs (if applicable) : zhihu.com (register + log in + and get some feeds)
OS version               : 10.12.5 (16F73)
Behavior in Safari (if applicable): read aloud the *selected* text
Behavior in Firefox (if applicable): do a copy of the text, then read aloud whatever is *copied*

What steps will reproduce the problem?
(1) Enable by Setting -> Accessibility -> Speech, tick "Speak selected text when the key is pressed", (select a Chinese language may help better)
(2) Select some text in chrome, specifically in zhihu.com
(3) Press Command + Esc

What is the expected result?

This is feature in Mac which can be enable by Setting -> Accessibility -> Speech, tick "Speak selected text when the key is pressed". Then when the key (default to Command + Esc) is pressed, the system will read aloud the selected test.

In Chrome copy the select text and press Command + Esc should read aloud the *selected* text.

What happens instead?

In Chrome, it actually copies the text then read whatever is copied aloud, which is fine for some website, while for sites that has modified behavior for copying (i.e. adding copyright information, disable copy), it reads copied text instead of selected, which means:
- It's reading copyright information
- It's reading nothing as websites disables copy

Mac OS put this "Speak selected text" feature in Accessibility, to help people with reading problems, while in Chrome, it's not helpful as people needs accessibility have to hear extra information or they can't hear anything!

P.S. This feature works correctly in Safari (reading SELECTED text), and it can also be triggered by select -> right click -> Speech -> Start Speaking. While Start Speaking in Chrome worked before and now it's not reading anything.


 
Components: UI>Accessibility
Labels: Needs-Triage-M58
Cc: shrike@chromium.org
Owner: ellyjo...@chromium.org
Status: Assigned (was: Unconfirmed)
ellyjones@ - any idea where this happens in the code? I confirmed that Chrome is copying the selected text to the pasteboard before reading it, which is bad (it should not blow away whatever the user has copied there). If it for some reason needs to use a Pasteboard to read the selection it should use a temporary one.
That's weird. I have to imagine this is happening in RenderWidgetHostViewMac::SpeakSelection(), but I can't figure out how.

Comment 4 by shrike@chromium.org, Jun 13 2017

FWIW, this isn't reproducible for me all the time.

To see if this was a Chrome bug or an Appkit bug I commented out the code the SpeakText(), but I still got speech. Then I stuck a return in RenderWidgetHostViewMac::SpeakSelection() and still got speech. Then I realized that this special macOS feature to speak text on a hotkey must be implemented outside of the running application. Given that the feature needs the current text selection, it's probably telling the current application to Copy and speaking the results from the pasteboard. I'm guessing there is code that restores the pasteboard's original contents but maybe it doesn't work well with Chrome.

Actually, given that Copy needs to get text from the renderer, I'm thinking the Copy operation is asynchronous. That may be what's tripping up the pasteboard restoration code.
Project Member

Comment 5 by sheriffbot@chromium.org, Jul 13 2017

Labels: Hotlist-Google
NextAction: 2017-10-01
It is not likely that I will work on this any time soon. I'll set the next action for the start of Q4 but hang onto it.
The NextAction date has arrived: 2017-10-01

Sign in to add a comment