If you select the part of word using mouse from right to left, the right-click context menu contains active (black) the copy and cut items in the clipboard. Selection before selection of the item is not reset If you select the part of word using mouse from the left to the right, the right-click context menu contains non-active (light gray) copy and cut items in the clipboard, and the selection is reset. The phenomenon takes place in Fedora Core and is absent in Ubuntu and SUSE
The effect is occurred in Libreoffice versions 4 and 5 (both vanilla and distributive) on Fedora Core at least from 19 up to current version.
Not reproducible for me under Ubuntu 16.04 with LO 5.4.2 from Ubuntu PPA. (In reply to McAaron from comment #1) > The effect is occurred in Libreoffice versions 4 and 5 (both vanilla and > distributive) on Fedora Core at least from 19 up to current version. So you should file a bug report on the Fedora bug tracker. Best regards. JBF
(In reply to McAaron from comment #1) > The effect is occurred in Libreoffice versions 4 and 5 (both vanilla and > distributive) on Fedora Core at least from 19 up to current version. By Vanilla, do you mean build supplied by TDF? Can you repro with a fresh daily build: https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF/current/ https://wiki.documentfoundation.org/Installing_in_parallel/Linux Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20180530
(In reply to Buovjaga from comment #3) > (In reply to McAaron from comment #1) > > The effect is occurred in Libreoffice versions 4 and 5 (both vanilla and > > distributive) on Fedora Core at least from 19 up to current version. > > By Vanilla, do you mean build supplied by TDF? From oficial libreoffice site
Problem not fixed in https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF/current/master~2018-05-31_05.25.23_LibreOfficeDev_6.2.0.0.alpha0_Linux_x86-64_rpm.tar.gz It may be cursor position after selection from left to right stil stay out of selection -- right boundary of selected area has less pixel coordinate then cursor coordinate (rounding problem???).
A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
There is no selection reset bug in version 6.1.3. Thanks. ---------------- Fedora Core 27 Writer Version: 6.1.3.2 Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU threads: 4; OS: Linux 4.18; UI Rendering: default; VCL: gtk2; Locale: ru-RU (ru_RU.utf8); Calc: threaded
Oh, that's cool -> closing
This selection reset bug is back $ libreoffice6.4 --version LibreOffice 6.4.1.2 4d224e95b98b138af42a64d84056446d09082932 $ uname -srv Linux 5.4.18-100.fc30.x86_64 #1 SMP Fri Feb 7 14:37:00 UTC 2020
(In reply to McAaron from comment #10) > This selection reset bug is back > > $ libreoffice6.4 --version > LibreOffice 6.4.1.2 4d224e95b98b138af42a64d84056446d09082932 > $ uname -srv > Linux 5.4.18-100.fc30.x86_64 #1 SMP Fri Feb 7 14:37:00 UTC 2020 For completeness, please copy and paste here the contents of your Help - About.
@LANG=ru_RU.utf8 Версия: 6.4.1.2 ID сборки: 4d224e95b98b138af42a64d84056446d09082932 Потоков ЦП: 8; ОС: Linux 5.4; Отрисовка ИП: по умолчанию; VCL: gtk3; Локаль: en-US (ru_RU.utf8); Язык интерфейса: ru-RU Calc: threaded LibreOffice - это современное, с открытым кодом, простое в использовании средство обработки текстов, электронных таблиц, презентаций и т.п. См. журнал: 4d224e95b98b138af42a64d84056446d09082932 https://gerrit.libreoffice.org/plugins/gitiles/core/+log/4d224e95b98b138af42a64d84056446d09082932 Этот продукт предоставлен The Document Foundation. Copyright © 2000-2020 участники сообщества LibreOffice. LibreOffice основан на OpenOffice.org. @LANG=C Version: 6.4.1.2 Build ID: 4d224e95b98b138af42a64d84056446d09082932 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-US (C); UI-Language: en-US Calc: threaded LibreOffice is a modern, easy-to-use, open source productivity suite for word processing, spreadsheets, presentations and more. See Log: 4d224e95b98b138af42a64d84056446d09082932 https://gerrit.libreoffice.org/plugins/gitiles/core/+log/4d224e95b98b138af42a64d84056446d09082932 This release was supplied by The Document Foundation. Copyright © 2000–2020 LibreOffice contributors. LibreOffice was based on OpenOffice.org. --- Video of selection reset https://radikal.ru/video/BHuYQa49hEV
McAaron, have you ever tested with a fresh user profile?
Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
Dear McAaron, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear McAaron, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp
The problem remains the same for 7.1.0.1 Version: 7.1.0.1 Build ID: b585d7d90ab863bf29b2d110c174c0c2a98f3ee4 CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: en-US (ru_RU.utf8); UI: ru-RU Calc: threaded Video posted earlier (https://radikal.ru/video/BHuYQa49hEV) remains valid. If necessary, I сan provide a special variant of video for 7.1.0.1 from libreoffice.org (Build ID: b585d7d90ab863bf29b2d110c174c0c2a98f3ee4)
Xisco's last question was about resetting profile, but as this is originally from 2017 I guess you have erased your profile at some point
I think I can reproduce this or something similar, possibly related to comment 6 (on ~head as of about a week old source) - I think there's an asymmetry about partially selected characters. (I'm on Fedora 34, on xfce) a) Select a largeish font size (I'm using 32pt) b) type 'Hello world this is a test' (you don't want to trigger spelling stuff) c) Click in the left half of the 'w' and drag to the right, releasing while the pointer is still in the left half of the 'd' - at this point 'worl' is highlighted. d) Right click (without moving) - the selection is cleared, copy/cut are not shown in the menu e) Ensure there is no selection f) click slightly to the right of the 'd' and drag to the left, releasing while the point is still in the right half of the 'w' - at this point 'orld' is highlighted. g) Right click (without moving) - the selection is kept, copy/cut are shown in the menu So in both of these cases the right-click is performed slightly outside of the selection - just after overshooting a little; but overshooting by under a half character to the right keeps the selection, but overshooting by under a half character to the *left* clears it I'm not 100% sure if this is what the reporter is seeing, but I think it is
Oops, that's the wrong way around, it should be: but overshooting by under a half character to the left keeps the selection, but overshooting by under a half character to the *right* clears it
I can reproduce my case on Ubuntu 21.04 / LO 7.1.2.2 - so it's not a fedoraism.
The selection clearing is done in SwEditWin::SelectMenuPosition by the: bool bOverSelect = rSh.TestCurrPam( aDocPos ); ... if ( !bOverSelect ) { // create only temporary move context because otherwise // the query against the content form doesn't work!!! SwMvContext aMvContext( &rSh ); rSh.CallSetCursor(&aDocPos, false); } so there's a conversation to be had with TestCurrPam and friends to see how it decides 'OverSelect'
Thanks for reporting this issue. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Reproducible with: Version: 7.2.3.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 1; OS: Linux 5.3; UI render: default; VCL: gtk3 Locale: es-MX (es_ES.UTF-8); UI: en-US Calc: threaded Just select "Lorem" and right-click in the middle of the "m".
No need to use large font size. A large zoom level could help.
Direction of selection has nothing to do here. You can select with double click (or .uno:SelectWord). I think that bug title must be reworded.
I understand this to be the same issue as the lost selection on right-click of text selection in bug 111969. Marking as a duplicate. Thanks! *** This bug has been marked as a duplicate of bug 111969 ***