Bug 141739 - Highlighting applied after drag & drop (unexpected)
Summary: Highlighting applied after drag & drop (unexpected)
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Highlight-Color
  Show dependency treegraph
 
Reported: 2021-04-18 08:31 UTC by Telesto
Modified: 2022-03-27 07:02 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (8.55 KB, application/vnd.oasis.opendocument.text)
2021-04-18 08:32 UTC, Telesto
Details
Screencast (269.13 KB, video/mp4)
2021-04-19 17:22 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-04-18 08:31:51 UTC
Description:
Highlighting applied after drag & drop (unexpected)

Steps to Reproduce:
1. open attached file
2. Select the area starting with the green highlighting until purple
3. Drag it between 'the' and 'alley'

Actual Results:
Lightning gets formatted

Expected Results:
Lightning getting no formatted (it's between 'formatted area')


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: a809b2ab2553e946431699d9d7ac3f6209cbdd6b
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2021-04-18 08:32:06 UTC
Created attachment 171266 [details]
Example file
Comment 2 Telesto 2021-04-18 08:33:10 UTC
Also in
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL

and in
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 3 Heiko Tietze 2021-04-19 14:27:07 UTC
If you add text without formatting at the end of a section with formatting it continues. Makes a lot of sense, otherwise you wouldn't be able to format first and type later. => NAB
Comment 4 Telesto 2021-04-19 15:40:09 UTC
(In reply to Heiko Tietze from comment #3)
> If you add text without formatting at the end of a section with formatting
> it continues. Makes a lot of sense, otherwise you wouldn't be able to format
> first and type later. => NAB

Me not totally following. What do you mean with 'section'?

I'm talking about text without direct formatting, embedded between DF. And when moving the whole thing (so left DF (Highlighting, Auto formatting, DF (Highlighting) to an area with DF applied, suddenly the text in the middle getting formatting
Comment 5 Heiko Tietze 2021-04-19 15:44:45 UTC
(In reply to Telesto from comment #4)
> Me not totally following. What do you mean with 'section'?

Some characters. Just continue typing after applying DF- you want the, for example, yellow highlighting to be continued. Don't see a reason why moving text should behave differently.
Comment 6 Telesto 2021-04-19 17:22:41 UTC
Created attachment 171295 [details]
Screencast

(In reply to Heiko Tietze from comment #5)
> (In reply to Telesto from comment #4)
> > Me not totally following. What do you mean with 'section'?
> 
> Some characters. Just continue typing after applying DF- you want the, for
> example, yellow highlighting to be continued. Don't see a reason why moving
> text should behave differently.

This is about 'copy/paste' (drag drop) changing formatting/ Not about 'typing after DF'. Did you try the steps? 

Adding a screencast too :P
Comment 7 Jim Raykowski 2021-04-20 07:23:24 UTC
I think because there is not df character highlighting for 'lightning' this is the correct behavior. If you set character highlighting for 'lighting' it will use that when the block is selected and dragged and dropped between 'the' and 'alley'.
Comment 8 Telesto 2021-04-20 07:44:06 UTC
(In reply to Jim Raykowski from comment #7)
> I think because there is not df character highlighting for 'lightning' this
> is the correct behavior. If you set character highlighting for 'lighting' it
> will use that when the block is selected and dragged and dropped between
> 'the' and 'alley'.

@Jim
That's probably valid assumption ;-). However going without DF is functional. If DF is applied you can't use PS/CS styles anymore. In this case the 'empty' is filled with DF because of drag and drop.  And there is no 'active' option to mark something as NON-DF explicitly (so can't do anything to prevent the above)

But well I my perception the DF <-> PS/CS style methodology being kind of broken :P. If you apply DF you can't go back to non-DF (except for clear all formatting). 
This is actually not my first bug related this matter. Mike Kaganski and I holding slightly different opinion (euphemism) on the topic.

And true, this example here maybe bit of artificial; but that's not the point.