Description: When you use MacOS dictation in other application, the text is typed while you speak, and corrected on the fly. You can correct mistakes by typing with the keyboard, or add some words or line feed for example. In libreoffice, when you activate dictation, nothing happens. But as soon as you stop dictation, or when you type a character, everything that was dictated is typed instantanly. In short, dictation is unusable in LibreOffice and behaves differently than in other applications (firefox, thunderbird, chrome, OnlyOffice, ...) Should be just cosmetic but is very important for disabled peoples Steps to Reproduce: 1.activate dictation 2.dictate 3.stop dictation and see all the text coming in one block Actual Results: no text typed until the end of dictation Expected Results: text typing on the fly during dictation Reproducible: Always User Profile Reset: Yes Additional Info: intel silicon platform. Dictation does not need any internet connection. No AV in action. Tried the two last version of MacOS and the three last versions of LO. Same problem. May be the bug is linked to this OpenOffice bug (but not sure) : https://forum.openoffice.org/en/forum/viewtopic.php?t=109822
Michael: since it concerns accessibility, thought you might be interested in this one.
Created attachment 197413 [details] Screencast using dictation on macOS
I've never used this feature before and am not very familiar with macOS in general, but tried on my Mac mini (Sequouia 15.0.1, Apple M2 Pro chip) now, and dictation seems to be working in general. attachment 197413 [details] is a screencast showing how it behaves for me. (In reply to Laurent COOPER from comment #0) > Description: > When you use MacOS dictation in other application, the text is typed while > you speak, and corrected on the fly. You can correct mistakes by typing with > the keyboard, or add some words or line feed for example. > In libreoffice, when you activate dictation, nothing happens. But as soon as > you stop dictation, or when you type a character, everything that was > dictated is typed instantanly. > In short, dictation is unusable in LibreOffice and behaves differently than > in other applications (firefox, thunderbird, chrome, OnlyOffice, ...) > Should be just cosmetic but is very important for disabled peoples > > Steps to Reproduce: > 1.activate dictation > 2.dictate > 3.stop dictation and see all the text coming in one block What do you mean by "stop dictation"? Pressing the shortcut to disable dictation (pressing Ctrl twice in my setup)? (That's not needed for me.) Or stop talking for a few seconds? If the behavior shown in the attached screencast is not the expected one: Can you please describe exact steps of how you use this in another application, and what's different in LibreOffice, including the exact words you say and other interaction, e.g. how correcting while dictating works,... Can you attach a screencast showing the behavior in LO, and in another application for comparison? (And ideally, change the title of this bug to be more specific, as dictation itself seems to work fine in my tests at least.) Tested with self-compiled git master as of commit bf42162fc50d0c6f8e567d8765f8b14b96d7cc50 .
(In reply to Michael Weghorn from comment #3) > What do you mean by "stop dictation"? Pressing the shortcut to disable > dictation (pressing Ctrl twice in my setup)? (That's not needed for me.) Or > stop talking for a few seconds? What I noticed was when I repeated "This is a test" repeatedly without a break was the following: - In LibreOffice no text appears until after a pause - In Firefox and Safari when dictating into a web form (like this comment) text is display as I continue speaking and does not wait for me to pause @Laurent is that what you see?
This is exactly what Patrick says : if you use another application, words are typed as you speak. If you say a long phrase (this is a test multiple times), the text appears "on the fly". in LO, the text only appears after a pause or after you stop dictation. You can stop : - by staying silent for a while - by stopping with your double command touch - or in LO, typing any key stops dictation In firefox for exemple, I can dictate "this is a test" type "for" and then say "dictation". "This is a text" appears while I'm saying it, the for is written while i'm typing, and dictation does not stop, it's still listening, and it write "dictation" It's particulary useful when you have technical names you have to correct while dictating. Maybe the title should be changed to "dictation behaves differently than in other applications in macos" or "dictation is laggy and stop when key is hit on macos" ?
Created attachment 197422 [details] behavior on firefox (for exemple) behavior in firefox. typed as you speak, can be corrected, autocorrect himself.
Added a screencast using obs with firefox. Sorry, dictation is in french for me :)
(In reply to Laurent COOPER from comment #7) > Added a screencast using obs with firefox. Sorry, dictation is in french for > me :) Pas de problème. I can now reproduce the second bug that you described: pressing any keys turns off dictation. I will need to do some debugging and see if I can find a way to keep dictation on after any keys are pressed. @Michael I think I have an idea what is causing the first bug: the text events are being processed but LibreOffice's painting timers do not have a chance to run until there is a break. I don't know if this is a safe change yet, but the following test patch eliminates a lot of the drawing lag: diff --git a/vcl/osx/salframeview.mm b/vcl/osx/salframeview.mm index 681567f3a5fa..90d34f8ac7c6 100644 --- a/vcl/osx/salframeview.mm +++ b/vcl/osx/salframeview.mm @@ -2063,6 +2063,8 @@ - (void)setMarkedText:(id)aString selectedRange:(NSRange)selRange replacementRan mpFrame->CallCallback( SalEvent::EndExtTextInput, nullptr ); } mbKeyHandled= true; + + Application::Reschedule( true ); } - (void)unmarkText
(In reply to Patrick (volunteer) from comment #8) > @Michael I think I have an idea what is causing the first bug: the text > events are being processed but LibreOffice's painting timers do not have a > chance to run until there is a break. I don't know if this is a safe change > yet, but the following test patch eliminates a lot of the drawing lag: > > diff --git a/vcl/osx/salframeview.mm b/vcl/osx/salframeview.mm > index 681567f3a5fa..90d34f8ac7c6 100644 > --- a/vcl/osx/salframeview.mm > +++ b/vcl/osx/salframeview.mm > @@ -2063,6 +2063,8 @@ - (void)setMarkedText:(id)aString > selectedRange:(NSRange)selRange replacementRan > mpFrame->CallCallback( SalEvent::EndExtTextInput, nullptr ); > } > mbKeyHandled= true; > + > + Application::Reschedule( true ); > } > > - (void)unmarkText Thanks for looking into it! I'm not familiar with that code, but your corresponding https://gerrit.libreoffice.org/c/core/+/176100 seems reasonable to me if it doesn't cause any unexpected delays when using some kind of input method (due to processing potentially "unrelated" events.)
(In reply to Michael Weghorn from comment #9) > Thanks for looking into it! I'm not familiar with that code, but your > corresponding https://gerrit.libreoffice.org/c/core/+/176100 seems > reasonable to me if it doesn't cause any unexpected delays when using some > kind of input method (due to processing potentially "unrelated" events.) Thanks for reminding about the "unrelated" events. I had already forgotten about it but I have added that to the "TODO" section in the patch. What is interesting about dictation is that it is just another input method. But what is unique is that dictation runs a loop in a native timer. Native timers run while -[NSEvent nextEventMatchingMask:..] is blocked waiting for a regular event. So the dictation timer runs and its loop invokes the active NSView's input method selectors. Given the above, I should be able to limit the fix for the display lag bug to only when -[NSEvent nextEventMatchingMask:..] is blocked waiting for a regular event.
Can this be related also to bug 157130?
(In reply to Dennis Roczek from comment #11) > Can this be related also to bug 157130? It's probably a possibility for certain keyboards. Could you post which keyboard are you using in tdf#157130? I generally have my keyboard set to US QWERTY or Canadian and neither of those use a native "input method" like dictation. But other keyboards such as Japanese - Kana do use a native "input method".
(In reply to Patrick (volunteer) from comment #12) > Could you post which > keyboard are you using in tdf#157130? All de-de builtin laptop keyboards (QWERTZ) or bluetooth keyboards (also QWERTZ). I did not have tested the en-us mac until now. Might get that laptop later for testing 157130.
I have committed a fix for this bug. The fix is in today's (11 November 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
First of all, thanks for the speed of your fix. Impressive ! Tried the nightly build on an intel mac just now. It works as expected (you can't modify as you type on intel mac, it stops dictation, but it does the same in any mac) Will try this at home with an apple silicon hardware and give a feedback.
Created attachment 197566 [details] Open this file in Safari and click in the text area to test dictation
(In reply to Laurent COOPER from comment #15) > Tried the nightly build on an intel mac just now. It works as expected (you > can't modify as you type on intel mac, it stops dictation, but it does the > same in any mac) I don't have access to any Intel Macs so I only tested on Silicon Mac. On Silicon Mac, pressing the Escape key or inserting characters from the macOS Character Viewer stops dictation. However, after pressing any other keys, dictation is still active on my Silicon Mac running macOS 15.1. I have attached a simple HTML file with a text area that I open in Safari to compare LibreOffice's behavior. So if you see something unexpected in LibreOffice's dictation behavior on Intel Mac, can you check how Safari handles the same input?
LibreOffice behavior on intel Mac is perfectly correct and correspond to what is expected on firefox or thunderbird for exemple. I've tested the @tb-94df nightly build on silicon mac, the behavior is now perfectly correct (the test with the @tb-92df was not, in comparison) From my point of view, the bug is closed. Thank you so much, and nice job !
(In reply to Laurent COOPER from comment #18) > From my point of view, the bug is closed. That is excellent news! Unfortunately my fix was too late to be included in the upcoming LibreOffice 24.8.3 release scheduled for later this week but it will be in the following upcoming releases: - LibreOffice 24.8.4 scheduled for release at the end of December 2024 - LibreOffice 25.2 Alpha 1 scheduled for release at end of November 2024 In the meantime, if you find any bugs using a nightly master build, feel free to post comments for any dictation issues you find.
Just another +1 to confirm main build works as expected. This is a very useful improvement. Thanks for your efforts, Patrick! Tested with Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 908b85de630fd0d474491c4f2f7402cb39553150 CPU threads: 12; OS: macOS 15.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded