Bug 138179 - EDITING Drag n Drop from Windows Explorer local folder creates OLE icons displaying 8.3 filenames
Summary: EDITING Drag n Drop from Windows Explorer local folder creates OLE icons disp...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: OLE-Objects
  Show dependency tree / graph
 
Reported: 2020-11-13 09:35 UTC by NISZ LibreOffice Team
Modified: 2022-12-14 08:32 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Example file from Writer (14.52 KB, application/vnd.oasis.opendocument.text)
2020-11-13 09:35 UTC, NISZ LibreOffice Team 		Details
Screenshot of the problem in Writer (35.15 KB, image/png)
2020-11-13 09:35 UTC, NISZ LibreOffice Team 		Details
Example files with long names used to create the example file (57.35 KB, application/x-zip-compressed)
2020-11-13 09:35 UTC, NISZ LibreOffice Team 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2020-11-13 09:35:01 UTC 
Created attachment 167257 [details]
Example file from Writer

When a docx, xlsx or pptx file is drag n dropped from Windows Explorer to Writer from a local folder the resulting OLE icon has the file name displayed, but in 8.3 file name format.

Steps to reproduce:
    1. Have some longer filenames in a local folder on c:\
    2. Drag n drop those files into a new Writer document

Actual results:
OLE icons appear, displaying filenames in 8.3 format.

Expected results:
OLE icons appear, displaying full filenames in readable format.

LibreOffice details:
Version: 7.1.0.0.alpha1+ (x64)
Build ID: 693553210828538680408832157faad9654758c8
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL
Comment 1 NISZ LibreOffice Team 2020-11-13 09:35:21 UTC 
Created attachment 167258 [details]
Screenshot of the problem in Writer
Comment 2 NISZ LibreOffice Team 2020-11-13 09:35:52 UTC 
Created attachment 167259 [details]
Example files with long names used to create the example file
Comment 3 Dieter 2020-11-30 07:28:53 UTC 
I confirm it with

Version: 7.1.0.0.alpha1+ (x64)
Build ID: 10b23330a9655658e6d7ef1d008a3302a15e9629
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded

Additional information:
If you drag and drop odt-file, a section is generated and link to document has also 8.3 format
Comment 4 NISZ LibreOffice Team 2021-05-04 08:04:27 UTC 
See also the sister bug 138180: drag and drop from a network share generates an icon with the full file name, even if that name is very long.
Comment 5 NISZ LibreOffice Team 2021-05-04 11:29:27 UTC 
I'm not sure anymore what's up...

I can't reproduce this on

Version: 7.1.3.0.0+ (x64) / LibreOffice Community
Build ID: 296c1b3b7e2fca6d54e3e61684d70d12f7989624
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL

from bibisect-7.1 repo, neither with the 
Build ID: 693553210828538680408832157faad9654758c8
version when checked out.

Now all docx, xlsx, pptx files are inserted as embedded documents, i.e. not icons.

Maybe the Win10 upgrade of my work computer did this... anyways, filed bug #142079 to make the embed format configurable, if that happens, this issue will be easy to reproduce even for me.