Description: Cell contents may be edited either with a total change by simply selecting the cell and typing new contents into the contents/formula bar or, selective modification directly in the cell or the contents/formula bar - by double-clicking the cell and typing appropriately in either of the two locations. When the amendments are typed into the CELL then all the selection, erasure and overtyping procedures perform as anticipated. However, when the amendments are effected in the contents/formula bar then there are anomalies in the selection process. I have observed content corruption but as yet, have been unable to identify and therefore demonstrate the immediate actions which precipitated that corruption. What is demonstrated herewith is the persistent anomaly when a singleton character is the starting point for selection and amendment. Attached are both the simple .ods and a .mp4 demonstrating the anomaly. Steps to Reproduce: The attached .mp4 demonstrates the actions on the attached .ods. You will notice that the effect is predominant when the singleton "a" character at the penultimate word location in the text is determined as the starting point for a left wise selection. The effect may sometiomes be "masked" by other intermediate (and indeterminate) activities around the sheet but will return. Sometimes, an alternate valid selection preceding the rogue will negate the effect of the rogue singleton starting point but clicking outside the cell and double clicking the cell and commencing with the selection attempt in the contents/formula bar will always reproduce the issue. Precise Steps; Double click on B8 to commence editing Cursor anywhere in the cell and simply click and move to select some text. Abandon it and select another chunk Moving left or right still selects a chunk Click outside the cell to deselect NOW Double click B8 again Go to the cell contents line and proceed to edit there Place your cursor in the middle and start to select a chunk to the left Release the cursor and observe that the text is selected in both the cell and the content. Now move the cursor to the right of the singleton character “a” - the penultimate “word” and move the cursor ONE character left. Observe how just the singleton is selected and a “No Entry” symbol is produced. If the cursor is moved further to the left it will at its own volition either “select” a larger chunk or simply continue to display the "No Entry" symbol - I have even experienced "corruption" of the contents when the mouse is released. Without deselecting the character move the cursor out of the box and then re-enter the box at the extreme left - everything is selected Again, without deselecting, exit and re-enter the box at the extreme right. My experiments indicate that if Ctrl+C is executed whilst the text is selected, it is copied to the clipboard. However, if another mouse click is effected without the copy action then the selection is “lost”. It would be nice to assume it’s some kind of “select to here” functionality but the activation is random so the function is not much use. Actual Results: See .mp4 attached Expected Results: The same result for both the cell and the content/formula bar Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 7.2.1.2 (x64) / LibreOffice Community Build ID: 87b77fad49947c1441b67c559c339af8f3517e22 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: sv-SE (en_GB); UI: en-GB Calc: threaded
Created attachment 175856 [details] Small .ods & .mp4
With further experiments, I am now able to demonstrate the additional anomalous behaviour to which I alluded in the original report. I've attached a replacement archive with a modified sheet containing some numerical cells and a formula together with a new .mp4. Whilst I feel this archive makes the first attachment redundant I have not marked it as such because somebody may still wish to refer to the anomaly pertaining to the simple text editing. Perhaps one of the "Big Boys" could make that judgement call. I have "undone" the change I edited into the formula cell to enable you to replicate my amendments or indeed contrive a few of your own. I would also observe that it's possibly related to my earlier report 144914
Created attachment 175886 [details] Supplement or potential replacement for attachment 175856 [details]
(In reply to Colin from comment #3) > Created attachment 175886 [details] > Supplement or potential replacement for attachment 175856 [details] Both attachments appear to be labelled 175856 - not sure how that works.
Further insight. I have been experimenting with the "scope" of the error as I had noticed that attempting to edit or replace a portion of the formula which may be embedded in perhaps the second or third level of parenthesis often resulted in the error condition. I now believe that the anomaly is connected with the validity of the underlying formula. That is to say If I attempt to correct a formula that contains a syntax error and results in an error message then the editing appears to proceed without the anomaly - it allows me to correct the invalid entry without hindrance. However, if I endeavour to edit a correctly formulated statement with a valid result then the anomaly occurs and it will destroy the syntax and render the formula invalid - even as insignificant as changing the target reference or the operator for a SUBTOTAL()function.
Obviously, the workaround is to just locate the insert point and either [delete] or [backspace] the target portion of the formula and then retype or paste the correction. This procedure has also highlighted the fact that after an indeterminate number of editing success units, the ability to select target text for action temporarily returns, as I said - temporarily.
tested selection as in video in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: c13db6e792cc347ffff4585f23866f195651f21f CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: x11 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo and it looks good to me. With Version: 7.1.7.2 the selections behave differently, as you describe. Please could you test it with dev version? You can download it here: http://dev-builds.libreoffice.org/daily/master/ Thank you
(In reply to zcrhonek from comment #7) > Please could you test it with dev version? You can download it here: > http://dev-builds.libreoffice.org/daily/master/ > Thank you Noobie. Would that be this? Win-x86_64@tb77-TDF 2021-12-29 04:49:59 I ask because the date and time appear to be a day earlier than your request.
(In reply to zcrhonek from comment #7) > tested selection as in video in Version: 7.4.0.0.alpha0+ / LibreOffice > Community > Build ID: c13db6e792cc347ffff4585f23866f195651f21f > CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: x11 > Please could you test it with dev version? You can download it here: > http://dev-builds.libreoffice.org/daily/master/ > Thank you I notice that you refer to the Linux release. I have Win10 so I downloaded and tested the version I identified above. No change for me, it still produces the "no entry" sign. Again, with temporary remediation once a few operations have been executed. What I should perhaps identify is that when the editing is upon a real live formula, as opposed to just some "Lorem", then attempting to edit that formula results in a formula corruption - even a simple change like =SUM(J45,J46,J47,J48)and attempting to replace CURSOR DRAG SELECTED J45 (NOT DOUBLE CLICK SELECTED J45) with perhaps J35 can produce something like =SUM(J4J355,J46,J47,J48) where it appears to use the "overtyping" as an edit insert at this location. Perhaps I should have used something more meaningful in my original definition than a simple "Lorem". My bad, I was trying to keep it simple but in mitigation, I had previously reported a significant and similar formula corruption - see 144194 - which I felt may be related but were not necessarily the same bug.
Repro using Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: a14d8acb93717b958598421590831e8a92fde27c CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL It is a regression. It didn't misbehave in *some* earlier versions. Note that it does not happen in 100% attempts, so some experimentation is required to see it, so bisection would be complicated.
(In reply to Colin from comment #4) > (In reply to Colin from comment #3) > > Created attachment 175886 [details] > > Supplement or potential replacement for attachment 175856 [details] > > Both attachments appear to be labelled 175856 - not sure how that works. No, the one that you attached in comment 3 is labeled 175886 (see 86 in the end), unlike the one added in comment 1 (175856) that ends with 56.
(In reply to Colin from comment #2) > I would also observe that it's possibly related to my earlier report 144914 I assume that you referred to some different number, since bug 144914 looks unrelated, and is not filed by you.
(In reply to Mike Kaganski from comment #12) > (In reply to Colin from comment #2) > > I would also observe that it's possibly related to my earlier report 144914 > > I assume that you referred to some different number, since bug 144914 looks > unrelated, and is not filed by you. Sorry Mike - My bad perhaps try 144194🤔
Regression after commit e087e25f05e689091cbf1c4f91b6e93878ac17ec Author Caolán McNamara <caolanm@redhat.com> Date Mon Oct 05 14:19:05 2020 +0100 weld InputBar For me, with attachment 175886 [details], it's reproduced most reliably by starting selection in cell E3 (as on Video), immediately after "F12", and dragging the mouse with pressed left button *slowly* to the left. It seems that DnD operation starts incorrectly then. I couldn't repro on Ubuntu, both with gtk3 and gen.
(In reply to Colin from comment #13) > perhaps try 144194🤔 A hint for the future: please use "bug nnnn" or "tdf#nnnn", not just "nnnn" or "report nnnn" or some such, so that Bugzilla creates proper links to the respective bugs. Bugzilla only knows a small number of keywords, like "comment", "attachment", "bug", "tdf#".
(In reply to Mike Kaganski from comment #15) > (In reply to Colin from comment #13) > > perhaps try 144194🤔 > > A hint for the future: please use "bug nnnn" or "tdf#nnnn", not just "nnnn" > or "report nnnn" or some such, so that Bugzilla creates proper links to the > respective bugs. Bugzilla only knows a small number of keywords, like > "comment", "attachment", "bug", "tdf#". Understood
The call stack: > sclo.dll!ScTextWnd::StartDrag() Line 1793 C++ > vcllo.dll!weld::CustomWidgetController::DragBeginHdl(weld::DrawingArea & __formal) Line 19 C++ > vcllo.dll!weld::CustomWidgetController::LinkStubDragBeginHdl(void * instance, weld::DrawingArea & data) Line 16 C++ > vcllo.dll!Link<weld::DrawingArea &,bool>::Call(weld::DrawingArea & data) Line 111 C++ > vcllo.dll!SalInstanceDrawingArea::StartDragHdl(VclDrawingArea * __formal) Line 6332 C++ > vcllo.dll!SalInstanceDrawingArea::LinkStubStartDragHdl(void * instance, VclDrawingArea * data) Line 6330 C++ > vcllo.dll!Link<VclDrawingArea *,bool>::Call(VclDrawingArea * data) Line 111 C++ > vcllo.dll!VclDrawingArea::StartDrag(char __formal, const Point & __formal) Line 2942 C++ > vcllo.dll!DragSourceHelper::DragGestureListener::dragGestureRecognized(const com::sun::star::datatransfer::dnd::DragGestureEvent & rDGE) Line 67 C++ > vcllo.dll!DNDListenerContainer::fireDragGestureEvent(char dragAction, long dragOriginX, long dragOriginY, const com::sun::star::uno::Reference<com::sun::star::datatransfer::dnd::XDragSource> & dragSource, const com::sun::star::uno::Any & triggerEvent) Line 404 C++ > vcllo.dll!ImplHandleMouseEvent(const VclPtr<vcl::Window> & xWindow, MouseNotifyEvent nSVEvent, bool bMouseLeave, __int64 nX, __int64 nY, unsigned __int64 nMsgTime, unsigned short nCode, MouseEventModifiers nMode) Line 514 C++ > vcllo.dll!ImplHandleSalMouseMove(vcl::Window * pWindow, const SalMouseEvent * pEvent) Line 2274 C++ > vcllo.dll!ImplWindowFrameProc(vcl::Window * _pWindow, SalEvent nEvent, const void * pEvent) Line 2613 C++ > vcllo.dll!SalFrame::CallCallback(SalEvent nEvent, const void * pEvent) Line 308 C++ > vclplug_winlo.dll!ImplHandleMouseMsg(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 3239 C++ > vclplug_winlo.dll!SalFrameWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam, bool & rDef) Line 5619 C++ > vclplug_winlo.dll!SalFrameWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 5972 C++ > user32.dll!UserCallWinProcCheckWow() Unknown > user32.dll!DispatchMessageWorker() Unknown > vclplug_winlo.dll!ImplSalDispatchMessage(const tagMSG * pMsg) Line 475 C++ > vclplug_winlo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 552 C++ > vclplug_winlo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 581 C++ > vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents) Line 474 C++ > vcllo.dll!Application::Yield() Line 559 C++ > vcllo.dll!Application::Execute() Line 452 C++ It looks like it tries to recognize a DnD gesture *irrespective* of the "selection in progress" status. The problem is likely in ImplHandleMouseEvent. No idea how to handle that, though. Hoping that Caolan knows how to deal with this :-)
(In reply to Mike Kaganski from comment #17) > The call stack: > > It looks like it tries to recognize a DnD gesture *irrespective* of the > "selection in progress" status. The problem is likely in > ImplHandleMouseEvent. No idea how to handle that, though. Hoping that Caolan > knows how to deal with this :-) Way above my pay grade. Does that imply I had correctly surmised a link between the two reports or that I'm a complete idiot for suggesting it?
(In reply to Colin from comment #18) It implies that I tried to provide as much as I could for Caolan (not Colin! ;)) who is the expert in this area (and whose change was identified in comment 14).
*** Bug 144997 has been marked as a duplicate of this bug. ***
hmm, we drag if there is a selection set and there is a mouse move. The selection however is (sometimes) set from a timer. aWTimer in SelectionEngine so sometimes there is a selection by the time the possible drag is considered. Looks to me that we can use EditEngine::IsInSelectionMode() to retrieve that there is an active selection being created and not draw when that is happening, can still drag with a selection, just not one that is currently being created.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d07acfc4b2cc92d094d8eac204868e26c9e25e27 tdf#145248 don't start a drag if actively selecting It will be available in 7.4.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.
that seems to solve it for me, done in trunk, backport to 7-3 in gerrit
*** Bug 149275 has been marked as a duplicate of this bug. ***
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/298815eab4724a9ac9a11f865d9b04edfd73ac66 tdf#145248 don't start a drag if actively selecting It will be available in 7.3.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.
It solves it for me, either. Thank you!
Is bug 149275 solved with those patches? https://bugs.documentfoundation.org/show_bug.cgi?id=149275 Did you verify that? You marked it as duplicate of this bug, but im not sure.
(In reply to santo.998 from comment #27) > Is bug 149275 solved with those patches? > https://bugs.documentfoundation.org/show_bug.cgi?id=149275 santo.998, if you have doubts, please download a recent daily build, and retest your bug with that.
*** Bug 151862 has been marked as a duplicate of this bug. ***