Hi, Using Orca master: 1. So far, ctrl-u enabled underline and said "Underline on/off". 2. Now, underline is still enabled, but Orca says only "Underline button". It is no longer able to describe it status, unlikely it does for italic, bold and other buttons. Regards
@Caolan: Could it be possible to request you help on this ? I aware you're very well familiar of UI :). Best regards, Alex.
I can reproduce this with: Version: 6.3.0.0.alpha0+ Build ID: 4aa8a6ab08b755e3d82860e8dbc294f854336477 CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-03-14_17:51:01 Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded
I can reproduce this on LibreOffice 6.0.6.2 but not on earliest release of LibreOffice 6.0 release cycle (5.4.0.0.alpha1+). I'll do a bibisect ASAP. Best regards, Alex.
This is the result of my bibisection on repo https://git.libreoffice.org/bibisect-linux-64-6.0: 39cd2b9108fd2b536bea08f5fb7ce97377bcd292 is the first bad commit commit 39cd2b9108fd2b536bea08f5fb7ce97377bcd292 Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri Jul 14 15:05:21 2017 +0200 source 52dfefec8da5d7f25c39218fd890cad6491728ab source 52dfefec8da5d7f25c39218fd890cad6491728ab :040000 040000 b2764b8359a7dadf360e7a6f377194e609ad9c7e 737a8c5bdefa4b67c32018b11be9ce838608fe45 M instdir Best regards, Alex.
@Jan-Marek Glogowski: it looks like it's your commit that has introduced this issue. I'm not a LibreOffice Developper, I've redo the bibisect a second time to be sure and it's your commit 52dfefec8da5d7f25c39218fd890cad6491728ab that has introduced this regression. Best regards, Alex.
I suggest to increase the severity of this issue at nowadays a blind person couldn't know if underline is enabled or disable when he does the shortcut. Is there a rule about severity of issues ? Best regards, Alex.
Hi Alex, Does it happen if you run LibreOffice with SAL_USE_VCLPLUGIN=gen ?
(In reply to Xisco Faulí from comment #7) > Hi Alex, > Does it happen if you run LibreOffice with SAL_USE_VCLPLUGIN=gen ? The gen backend seems completely inaccessible so I can't tell you. Otherwise, the issue appears both with GTK2 and GTK3 backends on my Debian 9 "Stretch". Maybe Patrick or Vstuart could confirm the issue on Windows. Best regards, Alex.
> Maybe Patrick or Vstuart could confirm the issue on Windows. It seems worse on Windows 10 with NVDA 2018.4.1, I obtain completely no feedback when activate/deactivate bold, italic or underline with LibreOfficeDev 6.3 built the 2019-04-05. Best regards, Alex.
On Windows 10 Home 64-bit en-US (1809) with NVDA 2019.1 and Version: 6.3.0.0.alpha0+ (x64) Build ID: 4ca9db953d59d93ce8e3a54a36d23ed52b9c62a9 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-26_03:34:16 Locale: en-US (en_US); UI-Language: en-US Calc: threaded On the Standard toolbar, the Underline button does report its status. Either with navigation via keyboard, or on mouseover. Program emits a "pressed" status that NVDA picks up and sounds. The same as for the other text attribute button actions visible by default--Bold, Italic and Strike-through.
(In reply to V Stuart Foote from comment #10) > On Windows 10 Home 64-bit en-US (1809) with NVDA 2019.1 and > Version: 6.3.0.0.alpha0+ (x64) > Build ID: 4ca9db953d59d93ce8e3a54a36d23ed52b9c62a9 > CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; > TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-26_03:34:16 > Locale: en-US (en_US); UI-Language: en-US > Calc: threaded > > On the Standard toolbar, the Underline button does report its status. > > Either with navigation via keyboard, or on mouseover. > > Program emits a "pressed" status that NVDA picks up and sounds. The same as > for the other text attribute button actions visible by default--Bold, Italic > and Strike-through. Do you confirm that it works when you select a text, keep the cursor into the document content and press control + u ? Best regards, Alex.
On Windows 10 Pro 64-bit en-US (1803) with NVDA 2018.4 and Version: 6.2.3.1 (x64) Build ID: 9ba025bafb03b962c34687cf87806cc03a3a7436 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded In Writer _none_ of the text attribute controls (Bold, Italic, Underline, Strikethrough) sound when their shortcuts are used while in document canvas. But they all sound when applied as "pressed" when formatting is applied from the Formatting toolbar (F10 - F6 - F6 and TAB to desired attribute), and then placing focus back on text cursor in document canvas (ESC). I'm not sure about prior releases, did this ever sound from document canvas? I'll have to play with it a bit.
(In reply to V Stuart Foote from comment #12) > In Writer _none_ of the text attribute controls (Bold, Italic, Underline, > Strikethrough) sound when their shortcuts are used while in document canvas. > And should have noted, the actual formatting applied is read back in NVDA when I have set NVDA preferences for Document Formatting from the Font block of types. So, events are consistently emitted ("pressed", or silent) for attributes set via the Toolbar input mechanisim, and resulting formatting is readback from document canvas. And events are consistently not emitted for text attributes set via keyboard accelerators. So, assume there is no linkage to the button status? Should it sound the button (formatting or style) state (pressed/released), or the state of the text attribute (applied/removed)? On Toolbar -> <Tab> onto button widget; "Bold pressed", "Underline released" While in document at text cursor -> via Keyboard <Ctrl+I> "Italic applied", <Ctrl+U> "Underline removed"
For 5.3 and at 5.3 the Underline command went through some changes in creating a Split button for use on Sidebar. Noticed when testing this against a 5.3 build that the Formatting toolbar was listed as a "Dropdown button" and was "checked" unlike the other "Button"(s) which were "pressed". At 5.3 we got two UNO controls (bug 101672): .uno:Underline -- which is now used on the Sidebar -> Properties deck (from 5.2.0 to current) .uno:UnderlineSimple -- which is now used on the Formatting toolbar (from 5.3.0 to current) At 5.3 Windows and NVDA still do not report the attribute changes with any of the shortcut/accelerators. Maybe should, but they were consistent. But is the disconnect in Orca somehow related to work on the Underline UNO control?
s/For 5.3 and at 5.3/For 5.2 and at 5.3/ And, at some point prior to 6.2 and master/6.3.0 (probably at 5.4.0) the split button is removed from the Formatting toolbar in favor of the UnderlineSimple control. I don't have a load of 5.4, 6.0 or 6.1 available to check against. But I'll poke at it later.
Dear Jean-Philippe MENGUAL, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Reproduced with Orca in recent trunk build, using both the Ctrl + U shortcut or pressing the toolbar button: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ff3fb42b48c70ba5788507a6177bf0a9f3b50fdb CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded However, I am not sure about the bibisection in comment 4 as I can reproduce the issue in 5.4.0.0.alpha1 as well as in 5.2.0.0.beta2. Text read is "Underline push button" without an on/off status. This is the same as for other split buttons like Font Color and Highlight Color, but it makes sense for them as they are not on/off toggles like the underline button is. Issue is the same for Bullet and Numbering list buttons, so probably a more general issue to fix with such "toggle split buttons". Michael W., you might be interested?
(In reply to Stéphane Guillou (stragu) from comment #17) > Text read is "Underline push button" without an on/off status. This is the > same as for other split buttons like Font Color and Highlight Color, but it > makes sense for them as they are not on/off toggles like the underline > button is. Bold/italic buttons have role ATSPI_ROLE_TOGGLE_BUTTON, while the underline button has ATSPI_ROLE_PUSH_BUTTON. All of them have a "checked" state set when active, so likely Orca has special handling for toggle buttons here. This will likely need looking into Orca source code and maybe coordination what's the proper way to expose it for Orca to announce it. There's also a "pressed" state that looks like it might be suitable, but it's currently not set. Technically "on/off" is enough to represent the bold/italic state fully, while underline has a wider range of possible values (off, single line, double line,...), but since the button is shown as pressed when any underline is used, screen readers should IMHO also announce it likewise. In any case, pressing Orca_Key+F to have Orca report text formatting makes Orca announce the underlined state when present, so that can be used to find out whether or not it's active for now.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d6c6472bbe1c90b733a4d69c4c8528f4de3750d3 tdf#123864 a11y: Add new AccessibleStateType::CHECKABLE It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d5a21cca3851488d904ef7d4d86ae8fa8cd3ec12 tdf#123864 gtk4 a11y: Handle CHECKABLE/CHECKED state independent of role It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Michael Weghorn from comment #18) > Bold/italic buttons have role ATSPI_ROLE_TOGGLE_BUTTON, while the underline > button has ATSPI_ROLE_PUSH_BUTTON. All of them have a "checked" state set > when active, so likely Orca has special handling for toggle buttons here. Indeed, Orca has this in `src/orca/scripts/apps/soffice/speech_generator.py` def _generateToggleState(self, obj, **args): """Treat toggle buttons in the toolbar specially. This is so we can have more natural sounding speech such as "bold on", "bold off", etc.""" result = [] role = args.get('role', AXObject.get_role(obj)) if role == Atspi.Role.TOGGLE_BUTTON \ and AXObject.get_role(AXObject.get_parent(obj)) == Atspi.Role.TOOL_BAR: if AXUtilities.is_checked(obj): result.append(messages.ON) else: result.append(messages.OFF) result.extend(self.voice(speech_generator.SYSTEM, obj=obj, **args)) elif role == Atspi.Role.TOGGLE_BUTTON: result.extend(speech_generator.SpeechGenerator._generateToggleState( self, obj, **args)) return result Since the Underline button can be checked/unchecked (or pressed/not pressed), I think that using the TOGGLE_BUTTON role for it (and other toolbar buttons with similar behavior) seems reasonable (at least for the AT-SPI case). I've started working on this, but noticed a few additional things that need some work while doing that. In addition, Qt currently doesn't have an equivalent for the TOGGLE_BUTTON role, and was not mapping the CHECKABLE state to AT-SPI, so that also needs changes on Qt side. First one: https://codereview.qt-project.org/c/qt/qtbase/+/517844
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8bc6119812223643b50dcd22c504f9f853976352 tdf#123864 a11y: Handle new CHECKABLE state in misc places It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eef4d5cbd10a042bd3b5fb555e0bf9b0dd7d1215 tdf#123864 a11y: Handle new checkable state for VCLXAccessibleMenuItem It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b7ba91311abaf1af4d97822e5c8eccc53b1e11fa tdf#123864 a11y: Evaluate checkable/toggle flag for more toolbar items It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a30f8ee1121aa2448be047f104a099b3272e6bde tdf#123864 gtk3 a11y: Consider states when mapping BUTTON_DROPDOWN It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This works as expected now for the gtk3 VCL plugin on Linux.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/f098ba6579fb1992c0db86b19b22eb8532ab1ba6 tdf#123864 a11y: Handle new CHECKABLE state in misc places It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/2bd0e347f15c50f354386b775d681243a5dd52a8 tdf#123864 a11y: Handle new checkable state for VCLXAccessibleMenuItem It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/b88198c183dfb10c97409e83ea5ad7793811e7fb tdf#123864 a11y: Evaluate checkable/toggle flag for more toolbar items It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/e8d18c73dbbf8cfcd972072510985d6bd18b2cca tdf#123864 gtk3 a11y: Consider states when mapping BUTTON_DROPDOWN It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to V Stuart Foote from comment #14) > At 5.3 Windows and NVDA still do not report the attribute changes with any > of the shortcut/accelerators. Maybe should, but they were consistent. There's an NVDA issue for this NVDA/Windows case ( https://github.com/nvaccess/nvda/issues/4248 ), now also tracked in tdf#160695 for the LO side.