Closed Bug 1279842 Opened 5 years ago Closed 5 years ago
Firefox is reading the ' character as "and number 39" on Reader Mode
User Agent: Mozilla/5.0 (Windows NT 10.0; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160604131506 Steps to reproduce: (Using Firefox Developer Edition 49.0a2 & Windows 10 for the test) 1. Go to: http://www.ghacks.net/2015/02/07/mozilla-starts-to-push-reader-mode-to-desktop-firefox/ 2. Start Reader Mode (didn't try it on android, it should be 100% reproducible on Windows, I guess) 3. Get to the "Mozilla has started to add Firefox ..." paragraph and hear what it says when it gets to the "Android's" word. Actual results: The Reader Mode says it as "Android and number 39 s ..." Expected results: It should have read it simply as "Android's". The same issue applies for example in the same mentioned page when it says "Type about:config in Firefox's address bar". "Firefox's" is being read as "Firefox and number 39 s". The same issue occurs whether I start the Reader Mode with Microsoft David Desktop or with Microsoft Zira Desktop. Not sure if that's even Firefox to blame..
I can't reproduce it with Nightly 50: http://i.imgur.com/J5arUQ9.jpg Did you test with a fresh profile? https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Component: Untriaged → Reader Mode
Product: Firefox → Toolkit
(In reply to Loic from comment #1) > I can't reproduce it with Nightly 50: http://i.imgur.com/J5arUQ9.jpg > > Did you test with a fresh profile? > https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove- > firefox-profiles I did, same results. I think I may have not made myself clear. I meant to the use of the "Narrate" function, when using Reader Mode. If you'll hear how it reads the "Android's" from your screenshot you should hear "Android and number 39 s".
Ah Ok, I didn't know the "narrate" function. In fact, I can reproduce it in FF50.
OS: Unspecified → All
Hardware: Unspecified → All
Version: 47 Branch → 49 Branch
Hmm, it seems it is bug within Firefox, since Windows read the same text in "Text to Speech" dialog (in Windows, go to Control Panel > All Control Panel Items > Speech Recognition) without "and number 39". http://thewindowsclub.thewindowsclubco.netdna-cdn.com/wp-content/uploads/2013/05/windows-8-speech.jpg
Eitan, any idea why this would be happening? Is there a better component for issues with our text to speech stuff?
Component: Reader Mode → Web Speech
Product: Toolkit → Core
Apparently it is reading the apostrophe code. This may be our fault. I'll investigate how we pass strings to the engine. It may also be the engine's fault..
It was pointed out to me that this is likely "amp" and not "and" which makes sense. That is it's reading: ' I reproduced this on Windows 10 in Nightly and Dev Edition (the only ones that have Narrate). Someone also reproduced this for me on Window 7. Someone tested this for me on Linux and reported that the issue did not occur.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Firefox 50.0a2 now reads it differently, for example "Android's" (from the link in the first post) is being read as "Android and hashtag thirty nine es". "hashtag" was "number" in previous versions. Not sure if I can call it an improvement :)
I tried the latest Nightly, it's still "Android and number 39 s".
(In reply to Loic from comment #10) > I tried the latest Nightly, it's still "Android and number 39 s". Odd, I've just tested with Nightly and I still hear "hashtag 39", not "number 39". Maybe that's because I've upgraded Windows 10 to the Anniversary update? That's the only change I've made to my system that may have triggered this change.
Yes, th speech engine is probably different between Win7 and Win10.
Hey i can reproduce this , ive developed this addon with webspeech which is active since ff43 https://addons.mozilla.org/en-US/firefox/addon/multilanguage-text-to-speech-t/ so ive used the tts api extensively since ff43 and this problem didn´t happen until ff49 or 50 (maybe 48) MY GUESS: its not in the webspeech itself but deeper in firefox textparsing, when you go to youtube make a comment with some " and ' , post it , then edit the comment and firefox´s textparser converts all the " and otehr extra signs back to their utf8 codes (i.e $ and similar ) so i think theres a textparsing function somewhere deep in firefox which can´t handle utf8 correctly!
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=29662e28a9c93ac67ee0b8ddfb65a9f29bbf73f5&tochange=0177462aac74605f426ab9c92e39bb467b7ce2d1 So probably bug 1237546. That's still in the web speech code.
This bug is a problem with languages using apostrophe as punctuation mark, like in French: l'école, j'ai froid, il s'en va, il m'aime etc.
Yeah. That seems to be the right regression. Just tested here. Looks like my advice there to use nsEscapeHTML2 was not the best.. We should simply be escaping < and >.
Sorry Makoto, you were right all along :P
Comment on attachment 8793406 [details] Bug 1279842 - Explicitly escape markup instead of using generic HTML escape function. https://reviewboard.mozilla.org/r/80150/#review79082
Attachment #8793406 - Flags: review?(m_kato) → review+
Actually, I didn't test the ampersand escape. I'm worried that "&" will be pronounced as "&". Once I'm back in front of Windows I'll test. Before that, not going to merge this..
Just needinfoing you to ensure this is on your radar, Eitan. Thanks.
Thanks for the reminder. Double checked the fix now, and it works.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/b4a218507afc Explicitly escape markup instead of using generic HTML escape function. r=m_kato
Should we uplift to aurora or beta?
Comment on attachment 8793406 [details] Bug 1279842 - Explicitly escape markup instead of using generic HTML escape function. Approval Request Comment [Feature/regressing bug #]: [User impact if declined]: Windows text to speech ends up somewhat garbled [Describe test coverage new/current, TreeHerder]: None [Risks and why]: Low [String/UUID change made/needed]:
Hello ItielMaN, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Comment on attachment 8793406 [details] Bug 1279842 - Explicitly escape markup instead of using generic HTML escape function. Regression in reader mode, Aurora51+, Beta50+
(In reply to Ritu Kothari (:ritu) from comment #30) > Hello ItielMaN, could you please verify this issue is fixed as expected on a > latest Nightly build? Thanks! Pretty much prefect :) Though a new issue arised- on some sentences, the orange underline thingy may go to the left (instead to the right) for a split second and then will continue to the rest of the sentence. It can be seen here, when firefox reads "Type about:config in Firefox's address bar and hit enter": http://www.ghacks.net/2015/02/07/mozilla-starts-to-push-reader-mode-to-desktop-firefox/ After "Type" is read, the underline goes to the left and goes back to the right. Will open a separate bug for this. Thank you!
(In reply to ItielMaN from comment #35) > (In reply to Ritu Kothari (:ritu) from comment #30) > > Hello ItielMaN, could you please verify this issue is fixed as expected on a > > latest Nightly build? Thanks! > > Pretty much prefect :) > Though a new issue arised- on some sentences, the orange underline thingy > may go to the left (instead to the right) for a split second and then will > continue to the rest of the sentence. > It can be seen here, when firefox reads "Type about:config in Firefox's > address bar and hit enter": > http://www.ghacks.net/2015/02/07/mozilla-starts-to-push-reader-mode-to- > desktop-firefox/ > After "Type" is read, the underline goes to the left and goes back to the > right. > > Will open a separate bug for this. > > Thank you! I can reproduce this, and noticed a bug was not on file yet (that I could see?) so I filed bug 1307002. Thanks for bringing it up!
This issue is VERIFIED FIXED on Windows 10 x64, Windows 7 x64 and Mac OS X 10.10.5 using: - Firefox Beta 50.0b4 (id: 20161003155957) - Firefox DevEdition 51.0a2 (id: 20161004004006) - Firefox Nightly 52.0a1 (id: 20161003030438)
You need to log in before you can comment on or make changes to this bug.