Description: hello every one. i heard about muffin in libreoffice which is activated by checking experimental features in tools, options, advance and also notebookbar in view menu and toolbars. i heard in the users mailing lists that its similar to ribbon menus in microsoft office! i have one question. do you make ribbon menus for all users default option? and also do you remove classic menu to have only ribbon like microsoft office in the future version of libreoffice? Steps to Reproduce: 1- in tools, options and advance activate Enable experimental features (may be unstable) and press okay. 2- in view menu and tools activate notebookbar. 3- activate nvda screen reader and try to access ribbon menus! Actual Results: ribbon menus are not accessible for screen readers and in general by using keyboard. Expected Results: ribbon menus should be accessible via keyboard. Reproducible: Always User Profile Reset: no Additional Info: i use windows xp 32bit, nvda 2016.4 and 2017.1 firefox 52 and i tested this problem with libreoffice 5.3.4, but i am sure thats a problem since introducing of notebookbar in version 5.3 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0
hello. today i tested libreoffice 5.4.0 and the ribbon menus (notebookbars) is still completely inaccessible for screen reader users.
(In reply to zahra from comment #0) > do you make ribbon menus for all users default option? The classic toolbar will remain the default. We don't plan to remove it. https://design.blog.documentfoundation.org/2016/12/21/evolving-past-the-restrictions-of-toolbars/ And since the Notebookbar is an alternative control aiming for individualization I would refrain from making all variants as accessible as possible. But that's a question for the whole team. Opinions?
(In reply to Heiko Tietze from comment #2) > (In reply to zahra from comment #0) > > do you make ribbon menus for all users default option? > > The classic toolbar will remain the default. We don't plan to remove it. > https://design.blog.documentfoundation.org/2016/12/21/evolving-past-the- > restrictions-of-toolbars/ > > And since the Notebookbar is an alternative control aiming for > individualization I would refrain from making all variants as accessible as > possible. But that's a question for the whole team. Opinions? hello. thanks so much for your answer and the link which you provided me. i was worried that libreoffice becomes like microsoft office with ribbon menu not classic one. i studied the link and bug reported related to it. i realized that my bug is duplicate of bug https://bugs.documentfoundation.org/show_bug.cgi?id=102059 thanks so much for your great program. i realy appreciate you, pray sincerely in my daily five times prayers and request divine infinite mercy and blessings for you.
(In reply to Heiko Tietze from comment #2) > And since the Notebookbar is an alternative control aiming for > individualization I would refrain from making all variants as accessible as > possible. But that's a question for the whole team. Opinions? Sorry, but we don't get to make that call Heiko--correct implementation of assistive technology is _required_ across the UI but fortunately is simple to implement in UI. We have rudimentary a11y support but are limited to F6 and TAB cycling. Mnemonics, with tooltips are provided but they are not exposed correctly as accessible events/targets while navigating with an AT. @Kendy, @Szymon?
(In reply to Heiko Tietze from comment #2) > (In reply to zahra from comment #0) > > do you make ribbon menus for all users default option? > > The classic toolbar will remain the default. We don't plan to remove it. > https://design.blog.documentfoundation.org/2016/12/21/evolving-past-the- > restrictions-of-toolbars/ > > And since the Notebookbar is an alternative control aiming for > individualization I would refrain from making all variants as accessible as > possible. But that's a question for the whole team. Opinions? today i also tested libreoffice 5.4 and could not use f10 to use ribbon and f6 for navigation. also tab does not work for me and ribbon menus are completely inaccessible for me using keyboard.
(In reply to V Stuart Foote from comment #4) > (In reply to Heiko Tietze from comment #2) > > > And since the Notebookbar is an alternative control aiming for > > individualization I would refrain from making all variants as accessible as > > possible. But that's a question for the whole team. Opinions? > > Sorry, but we don't get to make that call Heiko--correct implementation of > assistive technology is _required_ across the UI but fortunately is simple > to implement in UI. > > We have rudimentary a11y support but are limited to F6 and TAB cycling. > > Mnemonics, with tooltips are provided but they are not exposed correctly as > accessible events/targets while navigating with an AT. > > @Kendy, @Szymon? hi stuart. thanks so much for your reporting bug 102059 and your supporting for screen reader users! i pray for you every day and wish divine infinite mercy for you.
(In reply to zahra from comment #5) > today i also tested libreoffice 5.4 and could not use f10 to use ribbon and > f6 for navigation. > also tab does not work for me and ribbon menus are completely inaccessible > for me using keyboard. Zahra, please do not call it a Ribbon, that is a completely different proprietary Microsoft desktop API that we steer away from. As implemented in LibreOffice across all platforms--as part of our MUFFIN (My User Friendly & Flexible INterface)--the Notebookbars are alternative user interfaces to our traditional Menus and Toolbars. They also complement our Sidebar deck and its context menu GUI. The underlying controls are common--so current lack of exposure as accessible events is an implementation issue. And that will have to be corrected before the MUFFIN Notebookbar(s)--there are five currently--are removed from their experimental status probably at the 6.0.0 release. Otherwise the F10, F6 cycling of bug 102059 has been corrected. And normal keyboard navigation with TAB and Cursor movement between notebookbar widgets functions correctly, and tooltips are present on mouseover or for use with AT when exposed.
(In reply to V Stuart Foote from comment #4) > ...correct implementation of > assistive technology is _required_ across the UI but fortunately is simple > to implement in UI. We could understand MUFFIN in a way to create a Notebookbar variant explicitly focusing on accessibility. On the other hand we clearly defined the minimum requirements for keyboard interaction https://wiki.documentfoundation.org/Design/SideBar
(In reply to Heiko Tietze from comment #8) > (In reply to V Stuart Foote from comment #4) > > ...correct implementation of > > assistive technology is _required_ across the UI but fortunately is simple > > to implement in UI. > > We could understand MUFFIN in a way to create a Notebookbar variant > explicitly focusing on accessibility. Separate implementations for Accessibility is not an answer, that is not how we or any application supports a11y. Instead we provide framework for effective keyboard navigation and then attach accessible events across the UI. The integrated accessible events for components of the Notebookbar are missing. > On the other hand we clearly defined > the minimum requirements for keyboard interaction > https://wiki.documentfoundation.org/Design/SideBar Sure and keyboard navigation on the Notebookbar(s) are mostly correct, but even if keyboard navigation is sequenced correctly with no traps or dropouts, we need to correctly implement our existing support for GetAccessible() event handling of each widget. Also need to ensure correct packing order for TAB sequence across the Notebookbar(s), and support our use of Tooltips as annotation exposed to the AT. Picking up the accelerators and any defined short-cuts would just be gravy for an improved UX for a11y dependent users. This remains to be fixed on all of the Notebookbar flavors for MUFFIN interface.
Is this issue tackled in the current GSoC project? (Removing UX)
(In reply to Heiko Tietze from comment #10) > Is this issue tackled in the current GSoC project? > > (Removing UX) We will at least try to fix that I think.
Dear zahra, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
On Windows 10 Home 64-bit en-US (1903) with NVDA 2019.1 and Version: 6.3.3.2 (x64) Build ID: a64200df03143b798afd1ec74a12ab50359878ed CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded and current master/6.5.0 Version: 6.5.0.0.alpha0+ (x64) Build ID: 8c85782bbe46963e2be32c3cb406982f1790fc2f CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded Issue remains. And, if anything triggering of accessible events for a11y of the NB has gotten worse. Controls of the Notebookbar UI do not respond with accessible events. F10, F6 cycling is spotty. And there are keyboard navigation traps moving between control groupings. While no movement on bug 107343, leave a11y dependent users with no way to restore Main menu bar and its sounding keyboard navigation. The Contextual single Notebookbar mode can not be reached with keyboard only navigation. In short--it is not suitable to task and really needs dev attention.
(In reply to V Stuart Foote from comment #13) > The Contextual single Notebookbar mode can not be reached with keyboard only > navigation. Commit d6e8e41c22023bc15cc4c9659b33c1cc3d6edb75 changed many of the sfxlo-NotebookbarToolBox objects can_focus property from true to false. This caused notebook bars to lose ability to access many items using tab and arrow keys.
(In reply to Jim Raykowski from comment #14) > Commit d6e8e41c22023bc15cc4c9659b33c1cc3d6edb75 changed many of the > sfxlo-NotebookbarToolBox objects can_focus property from true to false. Andreas, this was your patch. Please take a look.
https://gerrit.libreoffice.org/#/c/83626/
andreas kainz committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b521f14f7c253113061798cb58fc3e565e92cb7d tdf#109425 NB accessibility event fix It will be available in 6.5.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.
andreas kainz committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/bc97c1c01807c304e67a42f2e0b4abb01f8702c7 tdf#109425 NB accessibility event fix It will be available in 6.4.0.1. 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.
Is it resolved:fixed now?
andreas kainz committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/2dba53d70e857be7161ba57de1a9e5a4f8fb9851 tdf#109425 NB accessibility event fix It will be available in 6.3.5. 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.
Hi Andreas, I should have jumped in earlier to let you know I was testing the patches. Here are some concerns I've found with Notebookbar_single.ui 1) I think Default-Grow and Default-Shrink buttons need to be visible. 2) Draw-FormatArea button does the same action as Draw-FormatArea2 button. There is differences in visible when horizontal/vertical and icon. Are both required? 3) Similar to 2, Grapic-GraphicDialog1 button does the same action as Graphic-GraphicDialog button in the GraphicContainer 4) Print preview only shows undo and paste buttons. To show all the buttons in the print container the visible property needs to be set to True. I haven't investigated why it is required in the .ui file to be set visible for the PrintContainer and not for the other containers. <object class="sfxlo-PriorityMergedHBox" id="PrintContainer"> <property name="visible">True</property> 5) Crash occurs in print preview when Close Preview button is pressed - can be reproduced in previous versions. I don't know much about XContextChangeEventMultiplexer addContextChangeEventListener which seems to be the cause of the crash. cssl::IllegalArgumentException("listener added twice", static_cast<XWeak*>(this), 0) get thrown. To work around this one or the other places illustrated below can be commented out. Hopefully someone with knowledge about this will find the following helpful. sfx2/source/notebookbar/SfxNotebookBar.cxx bool SfxNotebookBar::StateMethod(SystemWindow* pSysWindow, const Reference<css::frame::XFrame>& xFrame, const OUString& rUIFile, bool bReloadNotebookbar) { ... SfxViewFrame* pView = SfxViewFrame::Current(); if(pView) { Reference<XContextChangeEventMultiplexer> xMultiplexer = ContextChangeEventMultiplexer::get( xContext ); if(xFrame.is()) { ---> xMultiplexer->addContextChangeEventListener( pNotebookBar->getContextChangeEventListener(), xFrame->getController()); } } } return true; } vcl/source/control/notebookbar.cxx void NotebookBar::ControlListener(bool bListen) { if(bListen) { // remove listeners css::uno::Reference<css::ui::XContextChangeEventMultiplexer> xMultiplexer (css::ui::ContextChangeEventMultiplexer::get( ::comphelper::getProcessComponentContext())); xMultiplexer->removeContextChangeEventListener(getContextChangeEventListener(),mxFrame->getController()); } // remove this else block or comment out below in the SwPagePreview destructor and crash doesn't happen else { // add listeners css::uno::Reference<css::ui::XContextChangeEventMultiplexer> xMultiplexer (css::ui::ContextChangeEventMultiplexer::get( ::comphelper::getProcessComponentContext())); ---> xMultiplexer->addContextChangeEventListener(getContextChangeEventListener(),mxFrame->getController()); } } sw/source/uibase/uiview/pview.cxx SwPagePreview::~SwPagePreview() { SetWindow( nullptr ); SwViewShell* pVShell = m_pViewWin->GetViewShell(); pVShell->SetWin(nullptr); delete pVShell; m_pViewWin.disposeAndClear(); // if (SfxViewFrame* pCurrent = SfxViewFrame::Current()) // if (auto& pBar = pCurrent->GetWindow().GetSystemWindow()->GetNotebookBar()) //---> pBar->ControlListener(false); m_pScrollFill.disposeAndClear(); m_pHScrollbar.disposeAndClear(); m_pVScrollbar.disposeAndClear(); } framework/source/services/ContextChangeEventMultiplexer.cxx // XContextChangeEventMultiplexer void SAL_CALL ContextChangeEventMultiplexer::addContextChangeEventListener ( const cssu::Reference<css::ui::XContextChangeEventListener>& rxListener, const cssu::Reference<cssu::XInterface>& rxEventFocus) { if ( ! rxListener.is()) throw css::lang::IllegalArgumentException( "can not add an empty reference", static_cast<XWeak*>(this), 0); FocusDescriptor* pFocusDescriptor = GetFocusDescriptor(rxEventFocus, true); if (pFocusDescriptor != nullptr) { ListenerContainer& rContainer (pFocusDescriptor->maListeners); if (::std::find(rContainer.begin(), rContainer.end(), rxListener) != rContainer.end()) { // The listener was added for the same event focus // previously. That is an error. ---> throw cssl::IllegalArgumentException("listener added twice", static_cast<XWeak*>(this), 0); } rContainer.push_back(rxListener); }
Here is a patch to provide keyboard access to the grow and shrink buttons in notebookbar contextual single and to show print preview controls. https://gerrit.libreoffice.org/#/c/84105/
Here is a patch to make the send mail button keyboard accessible in the notebookbar tabbed compact tools tab: https://gerrit.libreoffice.org/#/c/84101/
This patch makes Before Text Indent, After Text Indent, Above Paragraph Spacing and Below Paragraph Spacing controls used in notebookbar tabbed compact layout focus correctly when using keyboard navigation. It also corrects images used for before, after, and above controls. https://gerrit.libreoffice.org/#/c/84103/
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d428f1e91575e743b624ec67699bc5b967889ca6 tdf#109425 Fixes for notebookbar single It will be available in 6.5.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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9a564c80ad48c116c261f37fea003c170ada14c4 tdf#109425 NB bar compact: Make send mail button kb accessible It will be available in 6.5.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.
Thanks Jim. Do you have also an view on other NB layouts?
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/65d3285536e3342c2b1b669d0dc8c134bc7254c6 tdf#109425 Make paraspacing windows grab focus It will be available in 6.5.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.
@Jim, Andreas On todays 2019-12-01 TB77 build of master with https://gerrit.libreoffice.org/#/c/83626/ Sorry but things are still not functioning well for keyboard navigation of the Notebookbar (NB), and corresponding a11y focus events are not being exposed. Also, basic F10, and F6 navigation into the NB remains defective. With NB defults to hide the Main menu, an F10 issued now places focus outside the LO app on its app frame, and AT sounds 'System subMenu' for its focus and of course F6 has no valid action at that point. Seems bug 107343 needs some love. With Main Menu closed, an F10 action either needs to land on the NB, or expose the Main menu and proceed to focus there. The more consistent action for F10--i.e. _always_ land on the main menu, exposing it if need be. And then correct F6 navigation to enter the NB.
(In reply to andreas_k from comment #27) > Thanks Jim. Do you have also an view on other NB layouts? Here is some keyboard navigation help for groupedbar compact: https://gerrit.libreoffice.org/#/c/84185/
Hi Jim I do update the different ui Files (a bit late) for the 6.4 release. So maybe we can work somehow closer together. You can find me in the libreoffice-design channel. I have to update the ui files to use the customize feature from our gsoc student.
Jim Raykowski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/83b4c4373e1d68f79fcf841799db21320297fc88 tdf#109425 Fixes for notebookbar single It will be available in 6.4.0.1. 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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/6e1f57551935250c45eb0c1c868f5d24842a5389 tdf#109425 NB bar compact: Make send mail button kb accessible It will be available in 6.4.0.1. 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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/9d55361562602a420103e28dfacac8f4d80ab1db tdf#109425 Make paraspacing windows grab focus It will be available in 6.4.0.1. 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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eb80ba799667973c3872904b3407a17ca3f6564a tdf#109425 KB navigation fixes for NB groupedbar compact It will be available in 6.5.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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/260c50e252abf6f4d523d9ed1c11fa407277087f tdf#109425 KB navigation fixes for NB groupedbar compact It will be available in 6.4.0.1. 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.
andreas kainz committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/328c9a674057759f616c584a8ae75ca018d10fdc tdf#109425 NB tabbed accessible for screen reader users It will be available in 6.5.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.
andreas kainz committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/6d8cc82c8340b80a690a3aaea380b964d15d7ff1 tdf#109425 NB tabbed accessible for screen reader users It will be available in 6.4.0.1. 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.
@Andreas, Jim, * So testing on Windows 10 Home 64-bit en-US with NVDA 2019.2 and todays TB77 Version: 6.5.0.0.alpha0+ (x64) Build ID: 790b5de8941d8f8d98c73ed1343289d7220211ad CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded The additional GTK Focus events have restored reasonable keyboard navigation to the NB, had a few sequencing issues within groupings, but so much closer now. Thanks! But for some reason the focus A11Y 'accessible events' are not fired when advancing through the NB in its nested position in the app frame. But if you reduce the width of the frame, collapsing the NB, the popup bar exposed with the 'chevrons' exposes all of the accessible events. What is different between controls held on the NB, versus the same controls held in the overflow 'chevrons' popup that allows the UNO controls 'accessible event' to fire? And otherwise, continue to have issues with a non-functional F10 & F6 movements when the main menubar is not exposed. Seems too fragile, and prone to losing track of position in the UI. No recovery with keyboard, requiring a blind mouse click into the document canvas to recover focus.
Issues remain on Windows 10 with NVDA screen reader and Version: 6.5.0.0.alpha0+ (x64) Build ID: 209fc9fd7fa433947af0bf86e210d73fa7f5a045 CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded Hidden Infobar landing resolved for bug 105518, but the NB is a black hole for UX when dependent on AT tools and keyboard navigation. And without reliable <F10> action(s) we are sending users out of frame with no <Esc> or <Ctrl><F6> keyboard recovery ( bug 107343 ).
Issue of no exposed 'accessible events' continues on Windows with NVDA (2019.3.1) and Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Dear zahra, 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
Issue of no exposed 'accessible events' for keyboard navigation in MUFFIN Notebook bar Tabbed UI continues on Windows with NVDA and Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 7716a43e76fe26ba31393b31cfa967f5fcb6e747 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Not just the Tabbed UI, affecting the other MUFFIN Notebook Bar modes as well.
Created attachment 182635 [details] Screencast showing a11y hierarchy in Accerciser with qt6 VCL plugin Announcement works with the gtk3 VCL plugin and Orca on Linux, but not with qt6. At a quick glance, the a11y hierarchy looks odd, since the notebookbar is on the same level as the "panel" that covers its area as well, s. attached screencast showing that in Accerciser. With an ugly quick demo change (that breaks rendering and probably all kinds of other things) to adapt that hierarchy and move notebookbar one level further down the hierarchy, Orca starts speaking the elements in the notebookbar for me with qt6 (+ a qtbase dev branch) as well. Same for NVDA on Windows, I'll attach a sample screencast for that one. Test change is this modified line (note the added `->GetChild(0)` with master as of commit 64e4363527422c913151efab0c0d0c6b8c2256c8: diff --git a/vcl/source/window/brdwin.cxx b/vcl/source/window/brdwin.cxx index 6617de6414b3..5649c9185714 100644 --- a/vcl/source/window/brdwin.cxx +++ b/vcl/source/window/brdwin.cxx @@ -1947,7 +1947,7 @@ void ImplBorderWindow::SetNotebookBar(const OUString& rUIXMLDescription, { if (mpNotebookBar) mpNotebookBar.disposeAndClear(); - mpNotebookBar = VclPtr<NotebookBar>::Create(this, "NotebookBar", rUIXMLDescription, rFrame, + mpNotebookBar = VclPtr<NotebookBar>::Create(this->GetChild(0), "NotebookBar", rUIXMLDescription, rFrame, aNotebookBarAddonsItem); Resize(); } Don't know whether that odd hierarchy is necessarily the root cause and changing that is the best way forward - and my VCL knowledge is too limited to be of much help here for a proper solution....
Created attachment 182636 [details] Screencast w/ NVDA with demo change from comment 45 in place
Thanks !