After changing a Sheet's format to Right-To-Left, the horizontal scrolling of the window gets broken. The sheet moves left when you scroll right and vice versa. The horizontal scrollbar also does not replace itself accordingly. It stays at left of screen, while it should be to the right. This makes it impossible to grasp it with the mouse and slide it as one would expect. Steps to reproduce: 1) Open a new Sheet. 2) Choose: Format -> Sheet -> Right-To-Left 3) Scroll the sheet left or right using the laptop's touchpad or a mouse's scroll-wheel. Notice how the sheet slides in the opposite direction! 4) Try to grasp the horizontal scrollbar at the button of window. See how that's impossible! I tested this using Mac OS X 10.10.4. Thank you.
(In reply to Mansour from comment #0) > > Steps to reproduce: > 1) Open a new Sheet. > 2) Choose: Format -> Sheet -> Right-To-Left I see this menu entry, but it is greyed out, thus inactive. How does one change the settings so that this entry is available ? OSX 10.10.4 Version: 5.0.0.5 Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b Locale : fr-FR (fr.UTF-8)
(In reply to Alex Thurgood from comment #1) > How does one change the settings so that this entry is available ? Tools->Options...->Language Settings->Languages. You need to enable there "Complex text layout (CTL)".
Created attachment 117888 [details] Wrong H. Scrollbar Alignment for Right-To-Left Sheets
Confirming on Version: 5.0.0.5 Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b Locale : fr-FR (fr.UTF-8) OSX 10.10.4 Wow, frustrating, like trying to play whack-a-mole ;-)
*** Bug 93559 has been marked as a duplicate of this bug. ***
Setting to NEW as alex, me, and duplicate bug confirmed it. This is a regression as it works in 3.3, but wasnt able to test it in 3.4 or 3.5.
I couldn't reproduce this with LibO 5.0.1 on Debian 64bit (both Debian's packages and LibO official build). Can anyone reproduce this on Linux/Windows? or this is a Mac OS X issue only ? (which the bug should reflect)
Tested in 3.5.7 and it works fine and it is still broken in master. Version: 5.1.0.0.alpha1+ Build ID: 1e67e94f1a308ca60d4934e9fe9d5c048225ebe8 TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-09-21_07:28:58 Locale: en-US (en_US.UTF-8)
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
*** Bug 94010 has been marked as a duplicate of this bug. ***
Still happening in LibreOffice 5.3.4 GTK3 Backend. Also tried VCL_BACKEND=gtk,kde4, and gen, and it's happening with all of them. I'm using Fedora 26 with GNOME Shell 3.24 and a touchpad.
I mean SAL_USE_VCLPLUGIN not VCL_BACKEND.
I tested in: Version: 6.0.0.0.alpha1+ Build ID: 6070dec9ca9a15587a2aece81f9ae1ab5ac0f8c4 CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: gtk3; Locale: en-US (en_US.utf8); Calc: group (Build from 2017-Nov-05 00:00) OS: Debian 64bit Stretch (Debian 9.2, with some backported packages) Works for me. In this version, reproduction instructions are different: Sheet > Right-To-Left (add checkmark) (P.S.: a capitalization style note - in the above menu you have "Right-To-Left" but in Insert > Formatting Mark > Right-to-left mark, i.e. there is different capitalization.)
Still affecting me. version: 6.4.6.2 OS: Zorin OS 15.3
(In reply to Hossein Shojaeifar from comment #15) > Still affecting me. > > version: 6.4.6.2 > OS: Zorin OS 15.3 I'm using version 7.0.3.1 and this happens for me too.
I'm not seeing the wrongly positioned scrollbar, but I'm seeing different scrolldirection: I checked using Shift-<mouse scrollwheel> in an RTL sheet, if rolling the wheel upwards scrolled left, I considered it good, if it scrolled right, I considered it bad. Bibisected to the following range using repo bibisect-43all, with 'gen' VCL plugin (SAL_USE_VCLPLUGIN=gen ./soffice). https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=b0da54bec69f4931af0adbc15d230d3f4eea7b08..bec62421a45da89d2812bdff30fbbab73291cf91 The following commit, fixing bug 44657 seems suspicious. https://cgit.freedesktop.org/libreoffice/core/commit/?id=bfa21ce5fa08f2c634ccb6162914be55aef9f3c2 author Jan Holesovsky <kendy@suse.cz> 2012-10-19 01:21:22 +0200 committer Jan Holesovsky <kendy@suse.cz> 2012-10-19 14:51:23 +0200 fdo#44657 Remove hack that "simulates" a mirrored horizontal scrollbar.
I cannot repro the error in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2f141c05a7205db660e79673ad2676e19d50583d CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL threaded Version: 6.4.0.3 (x64) Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8 CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: GL; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: CL Version: 5.4.7.2 (x64) Build-ID: c838ef25c16710f8838b1faec480ebba495259d0 CPU-Threads: 16; BS: Windows 6.19; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL I set the sheet RTL and the scrolling and the positioning of the scroolbar seems correct to me.
*** Bug 153207 has been marked as a duplicate of this bug. ***
We've seen this on macOS and Linux, but not Windows (I just checked again on Windows 10). See also confirmations in duplicate bug 153207. Changing summary and metas to more appropriate ones. Still reproducible with a recent master build: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: feda414f8b70f50a9f6745d2ce8828316d4711cd CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
*** Bug 154720 has been marked as a duplicate of this bug. ***
*** Bug 155693 has been marked as a duplicate of this bug. ***
Is there any update on this issue? It is really annoying
I want to report that this issue still persists on my Mac. MacOS version: 14.4 LibreOffice: 7.5.9.2 This bug was first reported 8 years ago and still is open. I wonder when we can expect to see an update on this. Thank you
No issue with kf5 but confirming for macOS (both v24.2). Not being able to scroll renders the application useless - high importance. Hossein, maybe it's not too difficult to adopt the patch from comment 17.
JIC, considering the dupes and several comments in those reports where some users are not able to reproduce the same behavior whereas others can, my guess is that the behavior might be different depending not only on setting RTL worksheet, but also it might depend on UI language. Using a RTL UI might behave differently than a LTR UI. Both context cases might need testing, in addition to setting the worksheet as RTL.
(In reply to ady from comment #26) > JIC, considering the dupes and several comments in those reports where some > users are not able to reproduce the same behavior whereas others can, my > guess is that the behavior might be different depending not only on setting > RTL worksheet, but also it might depend on UI language. > > Using a RTL UI might behave differently than a LTR UI. Both context cases > might need testing, in addition to setting the worksheet as RTL. I cannot reproduce this on macOS Sonoma. I built LibreOffice with all languages in my local macOS master build. Then I ran set the UI language to Hebrew in the System Preferences application, launched LibreOffice, and opened a new Writer document. The cursor is set to the right margin as expected so I increased the document zoom so that the document no longer fits with the window. Scrolling horizontally behaves the same of Microsoft Word. I also repeated the above test with the UI language set to Arabic in the System Preferences application and also scrolling horizontally behaves the same of Microsoft Word. Anything other combination I system UI and/or language within a document that I should try?: Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 80d401dd9ed4bfb06ed91c81050e76fb32efd2b5 CPU threads: 8; OS: macOS 14.2.1; UI render: Skia/Raster; VCL: osx Locale: ar-SA (ar_CA.UTF-8); UI: ar-SA Calc: threaded
(In reply to Patrick Luby (volunteer) from comment #27) > I also repeated the above test with the UI language set to Arabic in the > System Preferences application and also scrolling horizontally behaves the > same of Microsoft Word. > > Anything other combination I system UI and/or language within a document > that I should try?: OK. I now see it when I open a new Calc document. Although the "A" column is on the right edge of the window, the scroll bar is at the left side of the window like in attachment #117888 [details]. Swiping left or right appears to move the visible columns appears to be reversed in Calc as well. For example, with the "A" column on the right edge of the window, swiping left to right on the trackpad should shift the visible columns to the left (e.g. columns "H" or higher) but it instead tries to force the visible columns in the opposite direction. Conclusion: I believe that this is a bug in the Calc code. For me, the horizontal scrollbar layout and swiping behavior looks correct in Writer and Impress documents, but Calc is failing to flip both the horizontal scrollbar layout and the native horizontal scroll events that it receives.
(In reply to Patrick Luby (volunteer) from comment #28) > Conclusion: I believe that this is a bug in the Calc code. For me, the > horizontal scrollbar layout and swiping behavior looks correct in Writer and > Impress documents, but Calc is failing to flip both the horizontal scrollbar > layout and the native horizontal scroll events that it receives. After a little debugging, I think there are two separate bugs that will need to be fixed: 1. Swiping and mouse wheel: horizontal events cause Calc to move in the opposite direction than expected but are handled correctly in Writer and Impress. 2. Scrollbar display: I disabled the "use native scrollbar" code using the following debug patch and the non-native scrollbar is correctly positioned against the right edge of the window, Also, dragging the horizontal scrollbar thumb or clicking on the non-thumb of the scrollbar works correctly. So I am guessing that the macOS HITheme functions that draw a native scrollbar on macOS are flipping the direction of the horizontal scrollbar: diff --git a/vcl/osx/salnativewidgets.cxx b/vcl/osx/salnativewidgets.cxx index 8a7e81fd5d86..8b5ee27f9d96 100644 --- a/vcl/osx/salnativewidgets.cxx +++ b/vcl/osx/salnativewidgets.cxx @@ -135,9 +135,11 @@ bool AquaSalGraphics::isNativeControlSupported(ControlType nType, ControlPart nP return true; break; case ControlType::Scrollbar: +/* if (nPart == ControlPart::DrawBackgroundHorz || nPart == ControlPart::DrawBackgroundVert || nPart == ControlPart::Entire || nPart == ControlPart::HasThreeButtons) return true; +*/ break; case ControlType::Slider: if (nPart == ControlPart::TrackHorzArea || nPart == ControlPart::TrackVertArea)
OK. I think I am getting closer to finding the cause of the problem. I found that Calc calls ScrollBar::EnableRTL(true) when the UI is RTL. In contrast, Writer and Impress appear to always call ScrollBar::EnableRTL(false). So, AFAICT, is seems that Calc relies on the ScrollBar class to reverse any coordinates passed to it but I looked at ScrollBar::StateChanged() and it ignores StateChangedType::Mirroring (i.e. the state that represents ScrollBar::EnableRTL(true)). Several other control classes (e.g. listbox, text field, etc.) have logic for when ScrollBar::StateChanged(StateChangedType::Mirroring) is called so looks like that is where I'll focus next.
(In reply to Patrick Luby (volunteer) from comment #30) > Several other control classes (e.g. listbox, text field, etc.) have logic > for when ScrollBar::StateChanged(StateChangedType::Mirroring) is called so > looks like that is where I'll focus next. Nevermind. I really think that I am going to need to manually revert large chunks of the following patch that caused this bug. That patch removed reversing of the direction of how many cells to move horizontally when trackpad swipes and mouse wheel events occur. @Caolán: Am I missing something? By the time a swipe or mouse wheel event reaches the ScrollAdaptor, Calc has already calculated which columns to display in the range of visible columns use the wrong direction before it sets the thumb position: https://cgit.freedesktop.org/libreoffice/core/commit/?id=bfa21ce5fa08f2c634ccb6162914be55aef9f3c2 author Jan Holesovsky <kendy@suse.cz> 2012-10-19 01:21:22 +0200 committer Jan Holesovsky <kendy@suse.cz> 2012-10-19 14:51:23 +0200 fdo#44657 Remove hack that "simulates" a mirrored horizontal scrollbar.
Only had to revert a small portion of commit bfa21ce5fa08f2c634ccb6162914be55aef9f3c2 to get this RTL horizontal swiping and scrollbar clicking and dragging to work!: https://gerrit.libreoffice.org/c/core/+/164959 I still need to reimplement the original GTK issues that commit bfa21ce5fa08f2c634ccb6162914be55aef9f3c2 did fix.
OK. The following patch fixes this bug on macOS: https://gerrit.libreoffice.org/c/core/+/164959 Before I commit it, are there any Windows or Linux developers that can test this? If I don't hear from anyone, I'll go ahead and commit the patch so that Windows and Linux testers can test it.
(In reply to Patrick Luby (volunteer) from comment #33) > Before I commit it, are there any Windows or Linux developers that can test > this? If I don't hear from anyone, I'll go ahead and commit the patch so > that Windows and Linux testers can test it. Thank Patrick! I tested with my own build that includes your patch, on Ubuntu Ubuntu 22.04 + GNOME 42.9 + gtk3 VCL plugin: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded ...as well as gen. I tested mouse scroll as well as trackpad scroll. Fixed indeed! :)
...hm I spoke too fast about gen: it wasn't affected by the bug originally, and all interactions worked well. However, with your patch, the scrollbar arrows are now inverted: clicking the right arrow moves left, and vice-versa.
(In reply to Stéphane Guillou (stragu) from comment #35) > ...hm I spoke too fast about gen: it wasn't affected by the bug originally, > and all interactions worked well. > However, with your patch, the scrollbar arrows are now inverted: clicking > the right arrow moves left, and vice-versa. I am not surprised that the arrows are inverted. In my patch, all of the IsRTLEnabled() calls in the following code snippet in commit bfa21ce5fa08f2c634ccb6162914be55aef9f3c2 now return "false" instead of "true": https://cgit.freedesktop.org/libreoffice/core/diff/vcl/source/control/scrbar.cxx?id=bfa21ce5fa08f2c634ccb6162914be55aef9f3c2 I definitely need to restore the button swapping code but I'll need to add a new property since EnableRTL(true) causes all sorts of swipe and mouse event problems. So I'll likely add a new property all the IsRTLEnabled() calls in the above link with IsRTLEnabled() || IsRTLArrowsEnabled().
(In reply to Patrick Luby (volunteer) from comment #36) > I definitely need to restore the button swapping code but I'll need to add a > new property since EnableRTL(true) causes all sorts of swipe and mouse event > problems. So I'll likely add a new property all the IsRTLEnabled() calls in > the above link with IsRTLEnabled() || IsRTLArrowsEnabled(). After doing the above, the arrows in Linux scrollbars are still bahaving erratically. Unfortunately, I only have a Mac and macOS does not have arrows so I have found a way to fake it using the following debug patch. The debug patch doesn't draw any arrows but it forces LibreOffice to interpret any clicks within 100 pixels at each of horizontal scrollbars as arrows. With the following patch, I am seeing very similar behavior as reported on Linux so I should be able to find the source of the arrow problems: diff --git a/vcl/osx/salnativewidgets.cxx b/vcl/osx/salnativewidgets.cxx index 8a7e81fd5d86..c853a8ff4b84 100644 --- a/vcl/osx/salnativewidgets.cxx +++ b/vcl/osx/salnativewidgets.cxx @@ -100,10 +100,10 @@ static bool AquaGetScrollRect(/* TODO: int nScreen, */ rResultRect.SetTop(rResultRect.Bottom()); break; case ControlPart::ButtonLeft: - rResultRect.SetRight(rResultRect.Left()); + rResultRect.SetRight(rResultRect.Left() + 100); break; case ControlPart::ButtonRight: - rResultRect.SetLeft(rResultRect.Right()); + rResultRect.SetLeft(rResultRect.Right() - 100); break; case ControlPart::TrackHorzArea: case ControlPart::TrackVertArea:
diff --git a/vcl/osx/salnativewidgets.cxx b/vcl/osx/salnativewidgets.cxx index 8a7e81fd5d86..bd369032df1f 100644 --- a/vcl/osx/salnativewidgets.cxx +++ b/vcl/osx/salnativewidgets.cxx Updated debug patch so I won't forget how to debug arrows on macOS: @@ -100,17 +100,20 @@ static bool AquaGetScrollRect(/* TODO: int nScreen, */ rResultRect.SetTop(rResultRect.Bottom()); break; case ControlPart::ButtonLeft: - rResultRect.SetRight(rResultRect.Left()); + rResultRect.SetRight(rResultRect.Left() + 100); break; case ControlPart::ButtonRight: - rResultRect.SetLeft(rResultRect.Right()); + rResultRect.SetLeft(rResultRect.Right() - 100); break; case ControlPart::TrackHorzArea: - case ControlPart::TrackVertArea: case ControlPart::ThumbHorz: - case ControlPart::ThumbVert: case ControlPart::TrackHorzLeft: case ControlPart::TrackHorzRight: + rResultRect.SetLeft(rResultRect.Left() + 100); + rResultRect.SetRight(rResultRect.Right() - 100); + break; + case ControlPart::TrackVertArea: + case ControlPart::ThumbVert: case ControlPart::TrackVertUpper: case ControlPart::TrackVertLower: break;
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fbe350cb9f35039f8b10f8ac9aba6737cb5d84be tdf#93352 Fix horizontal swiping and scrolling when using an RTL UI 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.
I have committed a fix this bug. The fix should be in tomorrow's (22 March 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Verified for me as explained on gerrit. Thanks for this fix, Patrick! :)
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/227e51b6b4b3e6664c6ed9cc72c85ff3c3d03ab9 tdf#93352 Fix horizontal swiping and scrolling when using an RTL UI It will be available in 24.2.3. 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.