Bug 113219 - contents of the context menu after selecting a word with a mouse differs depending on the direction in which the selection was made
Summary: contents of the context menu after selecting a word with a mouse differs depe...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-18 09:57 UTC by McAaron
Modified: 2021-07-01 14:30 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description McAaron 2017-10-18 09:57:10 UTC
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
Comment 1 McAaron 2017-10-23 09:15:26 UTC
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.
Comment 2 Jean-Baptiste Faure 2017-10-23 20:41:29 UTC
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
Comment 3 Buovjaga 2017-11-07 16:17:19 UTC
(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.
Comment 4 QA Administrators 2018-05-30 16:39:37 UTC Comment hidden (obsolete)
Comment 5 McAaron 2018-05-31 15:36:14 UTC
(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
Comment 6 McAaron 2018-05-31 15:42:18 UTC
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???).
Comment 7 Xisco Faulí 2018-11-28 13:05:27 UTC
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.
Comment 8 McAaron 2018-12-02 07:33:04 UTC
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
Comment 9 Buovjaga 2018-12-02 08:41:56 UTC
Oh, that's cool -> closing
Comment 10 McAaron 2020-03-10 10:57:02 UTC
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
Comment 11 Buovjaga 2020-03-10 11:00:14 UTC
(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.
Comment 12 McAaron 2020-03-11 09:46:38 UTC
@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
Comment 13 Dieter 2020-05-15 15:52:05 UTC
McAaron, have you ever tested with a fresh user profile?
Comment 14 Xisco Faulí 2020-06-17 11:56:40 UTC
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
Comment 15 QA Administrators 2020-12-15 03:45:48 UTC Comment hidden (obsolete)
Comment 16 QA Administrators 2021-01-15 04:24:20 UTC Comment hidden (obsolete)
Comment 17 McAaron 2021-05-17 17:27:05 UTC
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)
Comment 18 Buovjaga 2021-05-17 17:50:55 UTC
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
Comment 19 Dave Gilbert 2021-06-06 01:42:57 UTC
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
Comment 20 Dave Gilbert 2021-06-06 01:46:18 UTC
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
Comment 21 Dave Gilbert 2021-06-06 11:51:40 UTC
I can reproduce my case on Ubuntu 21.04 / LO 7.1.2.2 - so it's not a fedoraism.
Comment 22 Dave Gilbert 2021-06-13 19:08:47 UTC
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'