Description: No Drag & drop of text Steps to Reproduce: 1. Open Writer 2. Type some text: say ABC 3. Press Enter a few times 4. Select & Drag ABC at the last line -> Not working.. same in tables Actual Results: No drag & drop Expected Results: Drag and drop Reproducible: Always User Profile Reset: No Additional Info: Version: 6.3.0.0.alpha0+ Build ID: aa51774e6a309f277e71ca3a3b9d5d5b4b3dbf1a CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-02-18_06:06:03 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
I confirm it with Version: 6.3.0.0.alpha0+ (x64) Build ID: f42554a1886ebe49170c25096dc3281b2c7bb1f4 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-02-08_22:37:30 Locale: en-US (de_DE); UI-Language: en-US Calc: threaded but not with Version: 6.1.5.2 (x64) Build-ID: 90f8dcf33c87b3705e78202e3df5142b201bd805 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group threaded
This seems to have begun at the below commit. Adding Cc: to Martin van Zijl ; Could you possibly take a look at this one? Thanks 85135f33c6a02d535ee2b8877b94dcd82f8b87cb is the first bad commit commit 85135f33c6a02d535ee2b8877b94dcd82f8b87cb Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri Feb 1 08:56:14 2019 +0100 source 31ba2a6bdecb81545d9b871a1a9394e5d7a3f2c4 author Martin van Zijl <martin.vanzijl@gmail.com> 2018-12-12 13:03:58 +1300 committer Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> 2019-02-01 08:40:24 +0100 commit 31ba2a6bdecb81545d9b871a1a9394e5d7a3f2c4 (patch) tree 005a1f3ff9987385ada45990fb4c540bd6348e49 parent a7082e565d7f8bccc822b2658592a4afbbf88d03 (diff) tdf#41202 allow decrease selection with shift-click in writer
Yes, I will take a look now.
Apologies, I must have accidentally introduced this bug in my patch. For now, I suggest we reverse my patch, like below: if ( !bOverSelect ) // <-- add this if statement again { MoveCursor( rSh, aDocPos, bOnlyText, bLockView ); bCallBase = false; } ...since dragging text is probably more useful than decreasing the selection with shift-click. I hope to try making it work for both scenarios, perhaps by setting bCallBase to true, or moving logic into the case statement on top of the method. But probably not till next week will I have the time.
*** Bug 123994 has been marked as a duplicate of this bug. ***
*** Bug 123997 has been marked as a duplicate of this bug. ***
@Martin Would you mind to push a revert patch into gerrit?
@Xisco Would you mind to do a revert of this one of the 6.2. branch.. looks like it made it into 6.2.. see bug 123994, didn't check it though
(In reply to Telesto from comment #8) > @Xisco > Would you mind to do a revert of this one of the 6.2. branch.. looks like it > made it into 6.2.. see bug 123994, didn't check it though Done -> https://gerrit.libreoffice.org/#/c/69132/
Reverted in https://cgit.freedesktop.org/libreoffice/core/commit/?id=d21aab7de8766e9575682f7f20f6449dbc9639e2
*** Bug 124257 has been marked as a duplicate of this bug. ***
*** Bug 124276 has been marked as a duplicate of this bug. ***
There are two recent reports, that it doesn't work in LO 6.2.2.2 => I reopen this bug
(In reply to Dieter Praas from comment #13) > There are two recent reports, that it doesn't work in LO 6.2.2.2 => I reopen > this bug From my test (vanilla 6.2.2.2 on Linux), drag&drop fails with KDE5 VCL plug-in, but works with the GTK3 one.
Yes, that solved my problem
Why is this issue closed? The problem is still present with KDE5 VCL plug-in!
(In reply to RGB from comment #16) > Why is this issue closed? The problem is still present with KDE5 VCL plug-in! Sorry, my communication skills :-) I moved the issue to a different bug report, as it is unrelated to this one (same effect, different cause).
(In reply to RGB from comment #16) > Why is this issue closed? The problem is still present with KDE5 VCL plug-in! Because that is a different bug and the fix comes after 6.2.2 (I confirm it is gone in master). Remember that the KDE5 backend is rough at this point. Distros shipping it right now are not making a wise decision. If it is not robust enough by 6.2.5, it might be made non-default under Qt shells. See the discussion in bug 124044
(In reply to Buovjaga from comment #18) > (In reply to RGB from comment #16) > > Why is this issue closed? The problem is still present with KDE5 VCL plug-in! > > (I confirm it Verified with Version: 6.4.0.0.alpha0+ (x64) Build ID: 2f2f4767089512c34514896bc37823f9310e9dd4 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-10_02:13:57 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded