really annoying: selection of word through dragging of mouse from left over word disappears if followed by mouse right click (to copy the word, e.g.) no prob if word is selected by dragging mouse from right or double-clicking...
Hi marc, I don't reproduce with LO 5.1.6.2 Build ID: 07ac168c60a517dba0f0d7bc7540f5afa45f0909 Threads CPU : 2; Version de l'OS :Windows 6.1; UI Render : par défaut; Locale : fr-FR (fr_FR); Calc: CL Can you precise your OS and the LO version? Did you install LO with a fresh profile? https://wiki.documentfoundation.org/Faq/General/110
you have to switch from drag-selecting to right-clicking w/o break... i am on xubuntu linux btw
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
Thank you for reporting the bug. it seems you're using an old version of LibreOffice. 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.
updated my libre office to Version: 5.4.1.2 Build ID: 1:5.4.1~rc2-0ubuntu0.16.04.1~lo0 prnblem still there...
mouse selection problem still not fixed in version 6.0.1.1. (xubuntu latest)
(In reply to marc from comment #6) > mouse selection problem still not fixed in version 6.0.1.1. (xubuntu latest) Does it happen with other programs like gerrit in Xubuntu or only LibreOffice?
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-20181009
bug is still there! Version: 5.1.6.2 Build ID: 1:5.1.6~rc2-0ubuntu1~xenial4 CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; Locale: pt-PT (pt_PT.UTF-8); Calc: group
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.
yes, it's still there in Version: 6.1.2.1 Build ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: pt-PT (pt_PT.UTF-8); Calc: group threaded
Repro. No problem with selection from right. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 9a373521d7a328197a4bf9abeb0a981b7acba896 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on 19 October 2018 Arch Linux 64-bit LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 Version: 6.2.0.0.alpha1+ (x64) Build ID: 8274c4c62df5b937b3f0bec9e1eeca85f3b219d4 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-22_01:47:50 Locale: fi-FI (fi_FI); Calc: threaded
Dear marc, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
bug confirmed with LO version Version: 5.1.6.2 Build ID: 1:5.1.6~rc2-0ubuntu1~xenial10 CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; Locale: en-US (pt_PT.UTF-8); Calc: group
Dear marc, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** Bug 157675 has been marked as a duplicate of this bug. ***
This is Writer-specific (not reproduced in Calc), and seems to be an issue only for about the right half of the last character. It is made obvious with a drag selection because the last character will become selected once reaching around that half-character limit. Moving the cursor back just a bit should keep the selection active when right-clicking. Reproduced in recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ff9c8b62c1015972e9e89799832fa3690dcd46b4 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 148872 has been marked as a duplicate of this bug. ***
*** Bug 113219 has been marked as a duplicate of this bug. ***
Not matter if do you select from left or from right. If do you secondary click in the right half (as noted by Stéphane Guillou) of the rightmost character selected, the selection is lost. Tested with "a⸻". Version: 7.4.7.2 (x64) / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-MX (es_ES); UI: en-US Calc: CL
*** Bug 132150 has been marked as a duplicate of this bug. ***
an accurate code pointer was identified in bug 113219 comment 22
I think the fix is - if (pCmp->HasMark() && *pCmp->Start() <= aPtPos && *pCmp->End() > aPtPos) + if (pCmp->HasMark() && *pCmp->Start() <= aPtPos && *pCmp->End() >= aPtPos) This is a bit scary because this logic has been untouched since initial import. The difference in aPtPos comes from TextFrameIndex SwFntObj::GetModelPositionForViewPoint // step back if position is before the middle of the character // or if we do not want to go to the next character if ( nIdx > rInf.GetIdx() && ( rInf.IsPosMatchesBounds() || ( ( nRight > tools::Long( rInf.GetOffset() ) ) && ( nRight - rInf.GetOffset() > rInf.GetOffset() - nLeft ) ) ) ) nCnt = nLastIdx - rInf.GetIdx(); // first half else nCnt = nIdx - rInf.GetIdx(); // second half
(In reply to Justin L from comment #23) > I think the fix is Nope - that also considers the first half of the next character to be included in the selection - just as bad in the opposite direction...
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/78fb5e63a4c4832181b92550df567e9b9fd56ba6 tdf#111969 sw: acknowledge that last half-character is in selection 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.
Thank you Justin for picking up this long-standing papercut! Fix verified in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fdc87dd56548622e13353b4cf9864232ee0110fb CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded It also fixes the issue that right-clicking the right half of the character preceding the selection wouldn't deselect. Related to this: I noticed this right-clicking "offset" also exists (and still exists) for the misspelling (red wiggly line) context menu! i.e. right-clicking the right half of the last underlined character doesn't pop up the corresponding context menu (or pops to next one), and right-clicking the right half of the last preceding character does bring it up when it shouldn't. Do you think the same bad logic is used there?
Created attachment 191458 [details] spellCheck.docx: off-by-half-a-character right-clicking
(In reply to Stéphane Guillou (stragu) from comment #26) > Do you think the same bad logic is used there? Yes. Other places where the logic is likely bad (but I don't know how to verify) are SwCursorShell::GetSmartTagRect (added in 2007 with 1e6e4d68ccf25bd5a82fc4d18a58abe24e0bbbb3, and https://bz.apache.org/ooo/show_bug.cgi?id=75130 doesn't help) SwVisibleCursor::getLOKPayload - // is cursor at a misspelled word ?
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5bc7d0186d1a70990377a2f4c630fe11e2dfd166 tdf#111969 sw: acknowledge that last half-character in Get*Correction 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.
Thanks Justin, I also verified the fix for the spellcheck selection in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 29b11fa3b5574dc3f42f55b0716f71054030c6c2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(In reply to Stéphane Guillou (stragu) from comment #30) > Thanks Justin, I also verified the fix for the spellcheck selection in: If you can figure out how to make a test document with SmartTags (whatever they are...), then we might be able to complete the loop for this code snafu.
(In reply to Justin L from comment #31) > (In reply to Stéphane Guillou (stragu) from comment #30) > > Thanks Justin, I also verified the fix for the spellcheck selection in: > If you can figure out how to make a test document with SmartTags (whatever > they are...), then we might be able to complete the loop for this code snafu. This? https://help.libreoffice.org/latest/en-US/text/swriter/guide/smarttags.html
(In reply to Buovjaga from comment #32) > This? That sounds exactly right. A completely unused feature? I only found one Apache reference to a "demo" smart tag extension, which doesn't seem to be working anyway? Probably not worth any further investigation...
Might be a candidate for https://wiki.documentfoundation.org/Proposals_for_removing_features Have to discuss it in the chat
Most recent Smart Tag related changes: 5242061cca5332ec15cce8c76f070d16e857445d only use css::awt::XPopupMenu methods a working example smart tag extension can be found at https://forum.openoffice.org/en/forum/viewtopic.php?p=387917#p387917 8d85b8c9670e34c0fa3f76272594a3267ff8da77 tdf#143464: fix SmartTag management by putting back missing information in lcl_FillRecognizerData Regression from e98711c14db9348f4d3f7d0f5bbde9276a3e73bc loplugin:unusedfields in sw (2018-12-12) So based on bug 143464 we can't remove it :)
Created attachment 191515 [details] SmartTagExample.oxt: (the only extension ever made?) tags $(variable) Smart tags broke in LO 7.5. After installing the OXT, open attachment 191514 [details] which contains a $(home) variable that should be marked as a smart tag. It demonstrates that smart tags need similar treatment as Grammar and selections.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7e32aec38ed386a01c522bbb5cf0e80dd924a815 related tdf#111969 fix smart tags job not being fired, due to typo 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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/7b147751b26c1a8af31c4b41a2a9db0cb70aa9b2 related tdf#111969 fix smart tags job not being fired, due to typo It will be available in 24.2.0.0.beta2. 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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/4dc47b93599793b4378992997f281ab6895262a6 related tdf#111969 fix smart tags job not being fired, due to typo It will be available in 7.6.5. 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5032244819e861899bc5f45bd097624ffa1caa40 tdf#111969 sw: acknowledge that last half-character for smart tags 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.
Thanks again Justin, this ended up being quite the rabbit hole! I verify the fixed smart tags (they are visible), but the half-character offset is still a problem in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0cd74b5be297f638d455b9b267462192f2e6620c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded I tested the Ctrl + click (should select the tag) as well as right-click (should show "smart tags" in context menu).
(In reply to Stéphane Guillou (stragu) from comment #41) > I tested the Ctrl + click (should select the tag) as well as right-click > (should show "smart tags" in context menu). Yup: more fixes in the queue, but they look dangerous...
Smart Tags are different from fields/hyperlinks/redlines because they aren't a portion, so they don't hit initial import's sw/source/core/text/itrcrsr.cxx SwTextCursor::GetModelPositionForViewPoint else if (bFieldInfo /* usually true */ && nLength == pPor->GetLen() /* is it end of the portion */ && (! pPor->GetNextPortion() || ! pPor->GetNextPortion()->IsPostItsPortion())) { --nLength; } By setting m_bPosMatchesBounds, this clause is now not hit for fields/hyperlink/redlines - producing the same end effect for everything that is involved.
The contents of the right-click menu are also off by 1/2 a character for pretty much everything. This one is a lot nastier because the menu is built from the cursor position of the mouse Point. Typically with SetCursor, we want the cursor to go to the "closest side", but in this particular case of defining a menu, we need the cursor to go to the "side that has the properties". sw/source/uibase/docvw/edtwin.cxx's SwEditWin::SelectMenuPosition rSh.CallSetCursor(&aDocPos, false) but this is super complicated because this could call one of 3 functions (SetCursor, SetCursorKillSel, Ignore) which calls SwCursorShell::SetCursor where we finally have a chance to set m_bPosMatchesBounds. So to fix this we would need to add a new + typedef tools::Long (SwWrtShell::*SELECTFUNC3)(const Point*, bool bProp, bool bBlock, bool bPosMatchesBounds); I'm not sure the hassle is worth it.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/90b12c9bad55e8f50b75a6d7b68caa27d82cc2b9 tdf#111969 sw: add selected smarttag to context menu 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.
Another complication is that things (like the right-click) can travel down a different code path in itrcrsr depending on if there is a single-length portion (like the preceding N-dash I used in all my testing). I also was testing redlines with a spelling mistake. If the spelling mistake was at the end and recognized by a dictionary, the last half-char right click worked fine, but with no dictionaries installed it didn't build a redline context menu. That suggests that a non-visible selection could be the answer??? I also noted that hyperlinks were a bit different - the first half-character in that particular case doesn't build a context menu either.
Created attachment 191574 [details] smarttag.docx: my testing document
(In reply to Justin L from comment #44) > I'm not sure the hassle is worth it. Possibly right-click menu fix at https://gerrit.libreoffice.org/c/core/+/161258 However that really emphasizes a quirk with hyperlinks (and probably any other fields) which start half-a-char late. The start of a hyperlink is not considered a hyperlink hint - not until there is a selection or the cursor is inside the field. (In reply to Justin L from comment #46) > That suggests that a non-visible selection could be the answer??? Looking better and better all the time...
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e73dfbf860b977f3b862fb75a87a7ad726d9a4c7 tdf#111969 sw: acknowledge field start/end for context menu 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/242f6985556af7aac77b68c6dfea20d4b32c5f52 tdf#111969 sw: acknowledge that last half-character for context menu 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/41452912e8ec11ecfead11588e7c70ad08903fd9 tdf#111969 sw: right-click menu recognizes start of hyperlink 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.
Thanks for the continued effort, Justin! Testing with: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 56767830b81fa21382b87cf43d78b1c73ca5dbd8 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded - Hyperlink tooltip, right-click and Ctrl + click: OK - Redline tooltip and right-click: OK - Spellcheck right-click: OK - Smart tag right-click: OK - Smart tag tooltip and Ctrl + click: still failing
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/062b4bee5eb06483cef3dde3f28a5d12599840d3 tdf#111969 sw: acknowledge that last half-character for popup/pointer 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a7649b85f1e16dd52378346958216e78b8335b5a tdf#111969 sw: acknowledge that last half-character for mouse pointer 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/788eb8e7b37373bd5d2c078a2a833c4357165178 fix build: Revert "tdf#111969 sw: acknowledge that last half-char 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/793853fbd1665e90ab91e9b45826174707617275 tdf#164703 tdf#111969 sw Get*Correction: only mouse passes PixelPos It will be available in 25.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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/5a6a6c146f3bd5d12d5426e64a49c2dc18028f5e tdf#164703 tdf#111969 sw Get*Correction: only mouse passes PixelPos It will be available in 25.2.2. 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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/0be2539f57599f33efb8b542faf4a4d3762ba1e4 tdf#164703 tdf#111969 sw Get*Correction: only mouse passes PixelPos It will be available in 24.8.6. 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.
It works inaccurately and depends on whether you are using a mouse or a laptop touchpad. After selecting on the touchpad, right-click on the touchpad button brings up the correct menu. When selecting with the mouse, right-click almost always moves the mouse slightly to the right and the menu comes up incorrectly. Perhaps it would be better not to use the automatic selection reset by right-click so that the correct menu is called up at any cursor position, but to reset the selection with left-click.