framework/source/uielement/generictoolbarcontroller.cxx | 28 +++++++++------- 1 file changed, 16 insertions(+), 12 deletions(-)
New commits: commit ea8767fe503384eeabda0d008acf748086d8ef66 Author: Neil Roberts <[email protected]> AuthorDate: Fri Oct 17 21:48:54 2025 +0200 Commit: Noel Grandin <[email protected]> CommitDate: Mon Oct 20 20:45:55 2025 +0200 tdf#138234 Focus the frame before executing toolbar action If a toolbar is floating then when a button is clicked on it the toolbar window will end up taking focus. This is kind of confusing if the button does an action such as inserting a table row. In that case you want the cursor to be visible in the document and to be able to immediately start typing in the new row. Note that despite the description in the bug report I think this is a general problem on all platforms and with all toolbar buttons. For example the cursor “disappears” in the same surprising way if you press the button to insert a footnote. To fix the problem this patch just makes it pass the focus to the toolbar’s frame before dispatching the command. This is similar to what is already done in the code for the font toolbar to handle when a new font is selected. Change-Id: Ifd941fb4ae295c57d465f4c8ff798913ce4a14c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192649 Tested-by: Jenkins Reviewed-by: Noel Grandin <[email protected]> diff --git a/framework/source/uielement/generictoolbarcontroller.cxx b/framework/source/uielement/generictoolbarcontroller.cxx index 0db12a966a23..f500adce46c8 100644 --- a/framework/source/uielement/generictoolbarcontroller.cxx +++ b/framework/source/uielement/generictoolbarcontroller.cxx @@ -149,6 +149,12 @@ void SAL_CALL GenericToolbarController::execute( sal_Int16 KeyModifier ) aCommandURL = m_aCommandURL; xDispatch = pIter->second; + + // tdf#138234 If this toolbar is a floating window then + // clicking on a button probably took the window focus. Let’s + // give it back to the toolbar’s frame. + if ( m_xFrame.is() && m_xFrame->getContainerWindow().is() ) + m_xFrame->getContainerWindow()->setFocus(); } css::util::URL aTargetURL; commit de5bdb5aa92390955b8a22710ea723df6a786e68 Author: Neil Roberts <[email protected]> AuthorDate: Fri Oct 17 21:41:30 2025 +0200 Commit: Noel Grandin <[email protected]> CommitDate: Mon Oct 20 20:45:44 2025 +0200 generictoolbarcontroller: Flatten the early-return checks in execute Instead of having a bunch of nested if statements in order to initialise xDispatch while the solar mutex is locked along with a check for whether the initialise happened after the lock is released, there are now just early returns on failures. This should make it a bit easier to add an extra step for the success case while holding the mutex in a subsequent patch. Change-Id: I731a800598a8e31b2b18ee29b6354c5440a430dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192648 Tested-by: Jenkins Reviewed-by: Noel Grandin <[email protected]> diff --git a/framework/source/uielement/generictoolbarcontroller.cxx b/framework/source/uielement/generictoolbarcontroller.cxx index 8ede4b601e9f..0db12a966a23 100644 --- a/framework/source/uielement/generictoolbarcontroller.cxx +++ b/framework/source/uielement/generictoolbarcontroller.cxx @@ -139,19 +139,17 @@ void SAL_CALL GenericToolbarController::execute( sal_Int16 KeyModifier ) if ( m_bDisposed ) throw DisposedException(); - if ( m_bInitialized && - m_xFrame.is() && - !m_aCommandURL.isEmpty() ) - { - aCommandURL = m_aCommandURL; - URLToDispatchMap::iterator pIter = m_aListenerMap.find( m_aCommandURL ); - if ( pIter != m_aListenerMap.end() ) - xDispatch = pIter->second; - } - } + if ( !m_bInitialized || !m_xFrame.is() || m_aCommandURL.isEmpty() ) + return; - if ( !xDispatch.is() ) - return; + URLToDispatchMap::iterator pIter = m_aListenerMap.find( m_aCommandURL ); + + if ( pIter == m_aListenerMap.end() ) + return; + + aCommandURL = m_aCommandURL; + xDispatch = pIter->second; + } css::util::URL aTargetURL;
