Today I noticed that holding Shift and pressing Up to select cells no longer works in Calc. Shift + Down does work. Can anyone else confirm this? System info Version: 7.4.0.2 / LibreOffice Community Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: threaded Not present in Version: 7.3.5.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.3.5-0ubuntu0.22.04.1 Calc: threaded
Also don't work with gen and gtk3. Also repro in LO 7.5+
Shift + Left also does not work.
With clear user profile it works again. But installing some extensions will break the shortcuts again. I need to investigate a bit further.
it works in Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 4e2ce2a460458f17ee4360c45a2da2fc4b4d753e CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded Jumbo Setting to NEEDINFO until futher info is provided
*** Bug 150412 has been marked as a duplicate of this bug. ***
(In reply to Xisco Faulí from comment #4) > Setting to NEEDINFO until futher info is provided Hi Xisco, considering that we have two other similar and recent bug reports about the same problem (see bug 150051 and bug 150412 - both in 7.4 beta), I believe there's something wrong we should look into. One thing I figured out is that the problem is not related to extensions since the user in bug 150051 did not have any additional extensions installed. From bug 150412 I found out that the problem may be related to the UI variant. When I switch to the standard toolbar (and then restart LO), all returns to normal. Selection starts working again as expected.
Steps to reproduce 1) On a new installation of LO 7.4 beta, notice it is using the standard toolbar; In Calc selecting with Shift + Up / Left works fine 2) Switch to the Tabbed UI variant (Apply to all); before restarting selecting with Shift + Up / Left still works 3) Now restart LO and open Calc; Selecting with Shift + Up / Left no longer works 4) Switch back to the Standard toolbar and restart; now selecting works again System info Version: 7.4.0.2 / LibreOffice Community Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: threaded
(In reply to Rafael Lima from comment #7) > Steps to reproduce > > 1) On a new installation of LO 7.4 beta, notice it is using the standard > toolbar; In Calc selecting with Shift + Up / Left works fine > > 2) Switch to the Tabbed UI variant (Apply to all); before restarting > selecting with Shift + Up / Left still works > > 3) Now restart LO and open Calc; Selecting with Shift + Up / Left no longer > works > > 4) Switch back to the Standard toolbar and restart; now selecting works again > > System info > > Version: 7.4.0.2 / LibreOffice Community > Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e > CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) > Locale: pt-BR (pt_BR.UTF-8); UI: en-US > Calc: threaded Reproduced in Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: da46f3db22814c03fbc303275342f7182ea288b4 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (C); UI: en-US Calc: threaded
Regression introduced by: author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2022-04-03 09:02:38 +0900 committer Tomaž Vajngerl <quikee@gmail.com> 2022-04-06 02:59:02 +0200 commit c6fecc628a60a3955c022f04020cdb515cc4fb6e (patch) tree 64debf2d425982dc37cf6b06e305e7707739fe97 parent ec18c7bf707e85d85f362d43454d35b1636de40f (diff) sc: add Group and Ungroup to context menu for sparklines Bisected with: bibisect-linux64-7.4 Adding Cc: to Tomaž Vajngerl
*** Bug 150051 has been marked as a duplicate of this bug. ***
@Caolán, @Heiko, any idea why this is only happening with the tabbed UI ?
For some reason the commands .uno:GoLeftSel and .uno:GoUpSel are disabled in the tabbed interface. If you run the following macro in LO 7.4 using the Tabbed interface, LibreOffice will stop responding and you'll have to kill its process. Sub SelectLeft dispatcher = CreateUnoService("com.sun.star.frame.DispatchHelper") provider = ThisComponent.CurrentController.Frame dispatcher.executeDispatch(provider, ".uno:GoLeftSel", "", 0, Array()) End Sub The macro above will work if you return to the standard toolbar and restart LibreOffice. So basically switching the interface is disabling these commands. I'm not sure if this is related, but I got these messages in the terminal after launching LO 7.4 from the terminal: warn:sfx.control:15433:15433:sfx2/source/control/dispatch.cxx:1206: Childwindow slot missing: 25917 warn:sfx.control:15433:15433:sfx2/source/control/dispatch.cxx:1206: Childwindow slot missing: 26189 warn:sfx.control:15433:15433:sfx2/source/control/dispatch.cxx:1206: Childwindow slot missing: 26190
(In reply to Xisco Faulí from comment #11) > @Caolán, @Heiko, > any idea why this is only happening with the tabbed UI ? Works for me with standard and tabbed UI Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: bd6cecbae44f4adce6e245bab46a88e86f068d99 CPU threads: 8; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded
same behaviour with GEN and GTK3. Shift up/left don't work
It's possible that commit just added enough entries in sc/inc/sc.hrc to cause some other entries to be then numbered high enough to overlap some other range of include/sfx2/sfxsids.hrc and there is some collision there between multiple slots now with the same id. No idea why it would only affect the tabbar ui though. It's possible that that e.g. removing those relatively new *SPARKLINE* entries from the block that ends with INSERT_MENU_END (and restoring INSERT_MENU_END to a lower number) and putting them instead down numbered after SID_CURRENT_FORMULA_RANGE would fix it. Or finding where the overlap is and what range reservation is the issue.
yeah, that's works. Lets try that as a presumably safe to backport to 7-4 fix.
seems that SID_CURSORLEFT_SEL and SID_PREVIEW_MARGIN (SID_CURSORUP_SEL and SID_PREVIEW_CLOSE) ended up with the same 26523 (26522) ids. there is that seemingly arbitrary #define SID_KEYFUNC_START (SID_SC_START + 521) in include/sfx2/sfxsids.hrc and adding entries in sc/inc/sc.hrc eventually pushed other slotids past the + 521 to create overlapping ids
(In reply to Caolán McNamara from comment #17) > seems that SID_CURSORLEFT_SEL and SID_PREVIEW_MARGIN (SID_CURSORUP_SEL and > SID_PREVIEW_CLOSE) ended up with the same 26523 (26522) ids. > > there is that seemingly arbitrary > #define SID_KEYFUNC_START (SID_SC_START + 521) > in include/sfx2/sfxsids.hrc > > and adding entries in sc/inc/sc.hrc eventually pushed other slotids past the > + 521 to create overlapping ids Hi Caolán, is there any way to assert this kind of overlapping at build time ?
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/673bff36bc310252dd4d95ca9e31a0f69ba4454d Resolves: tdf#150336 overlapping slot ids It will be available in 7.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.
(In reply to Xisco Faulí from comment #18) > is there any way to assert this kind of overlapping at build time ? yeah, I was wondering too: https://gerrit.libreoffice.org/c/core/+/138515 seems to work and would have caught this problem We have a related easy hack of bug 146150 to drop things that know the exact id number. it would be nice to be able to arbitrarily renumber these things, though I think the macro recorder records as "slot:", though again we marked that as experimental 10 years ago so its flagged that what that recorder does isn't desirable. In any case we should replace "slot:" in the odk if we could
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/d3492e15dce1dc8448c6444a92e3e2f7ec19571c Resolves: tdf#150336 overlapping slot ids It will be available in 7.4.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5dbd9a7bb934fbe182a3fa2423f506563bd1ef8f tdf#150336 add a static_assert to catch that happening again It will be available in 7.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/01a59744e4ebed4e10bea308623afdb6223162da tdf#150336 add a static_assert to catch that happening again It will be available in 7.4.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.