Issue metadata
Sign in to add a comment
|
Chrome is using copying to implement Speak selected text |
||||||||||||||||||||||
Issue descriptionChrome 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.
,
Jun 2 2017
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.
,
Jun 12 2017
That's weird. I have to imagine this is happening in RenderWidgetHostViewMac::SpeakSelection(), but I can't figure out how.
,
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.
,
Jul 13 2017
,
Aug 3 2017
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.
,
Oct 1 2017
The NextAction date has arrived: 2017-10-01 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by nyerramilli@chromium.org
, Jun 1 2017Labels: Needs-Triage-M58