Problem description: (1) Open new text document. (2) “Insert > File...”. A Windows dialog is openend in order to choose a file to be inserted. (3) Choose a picture file with the file extension jpg or png. Then “OK” or “Open”. The dialog closes and nothing is inserted. Expected: Display of an error message: “The file 'filename.jpg' cannot be inserted, hence it is not a text file.” or a similar message. Furthermore the menu item “Insert > File...” suggests that this is a general possibility in order to insert files and not only a possibility to insert text files. So, if a user expects this (insert picture), he may be quite irritated, if this is not possible. In order to avoid such an expectation, the menu item should be changed to “Text file...” or “Text document...”. Then, in the following Windows open dialog only files in text format, which can be inserted, should be displayed. This would be equal if you insert a picture from a file (Insert > Picture > From File...). Additional Info: In Impress and Draw you can also insert a file with the same menu item. If you try to insert a picture there, you get an error message. Operating System: Windows 7 Version: 3.6.4.3 release
Confirmed with: LO 4.1.0.0.beta2 Build ID: 33224f4f11a05cfad2249e812fcc2975fbb61f6 Windows 7 Professional SP1 64 bit No error message - nothing happens. Error message is present in Impress.
*** Bug 62100 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: ( needsDevEval difficultyInteresting skillDebug topicUI) [NinjaEdit]
topicDebug is a Topic.
Remove skillDebug, superceded by topicDebug.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Bug still exists in version 5.3.0. (Win7) Since version 4.4.0 the menu item is no longer "File..." but "Document...". This is little improvement. But it's still possible to select all kinds of files without an error message. Bug already exists in version 3.3.0. Hence inherited from OOo.
** Please read this message in its entirety before responding ** 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 still exists with version 6.1.1 (64 bit, Win 10). Meanwhile the menu item is "Text from File..." and no longer "Document...".
Dear Harald Koester, 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 still exists with version 6.3.2 (64 bit, Win 10).
Xisco/Heiko: I thought about adding a warn message containing: "File can't be converted to text" Would it be ok?
I gave a try with: https://gerrit.libreoffice.org/c/core/+/99941
You tell the user that Insert > File > (png) cannot converted to text ("File can't be converted to text"). This sounds a bit weird to me as I wouldn't expect such function. How about something like "Only odt, doc, txt files can be inserted". And since the command is now "Insert text from file..." a simple "This is not a text document" might also work. Btw, loading a PDF returns "Read error\nError reading file.", which is tech-talk. Either loading PDF as text is possible (and the actual reason is given why it fails) or the error message above applies as well.
(In reply to Heiko Tietze from comment #14) > You tell the user that Insert > File > (png) cannot converted to text ("File > can't be converted to text"). This sounds a bit weird to me as I wouldn't > expect such function. How about something like "Only odt, doc, txt files can > be inserted". And since the command is now "Insert text from file..." a > simple "This is not a text document" might also work. I think "This is not a text document" would be better since the text format files may be quite long, here we could at least add "docx" but perhaps also others. > > Btw, loading a PDF returns "Read error\nError reading file.", which is > tech-talk. Either loading PDF as text is possible (and the actual reason is > given why it fails) or the error message above applies as well. Indeed, I'll take a look.
The pdf part seems another problem. Here's part of bt: #6 0x00007fffef394f32 in ErrorHandler::HandleError(ErrCode, weld::Window*, DialogMask) (nErrCodeId=..., pParent=0x0, nFlags=DialogMask::MAX) at vcl/source/window/errinf.cxx:179 #7 0x00007fffde16c358 in SwView::InsertMedium(unsigned short, std::unique_ptr<SfxMedium, std::default_delete<SfxMedium> >, short) (this=0x6440070, nSlotId=5532, pMedium=std::unique_ptr<class SfxMedium> = {...}, nVersion=0) at sw/source/uibase/uiview/view2.cxx:2329 #8 0x00007fffde16ce3a in SwView::DialogClosedHdl(sfx2::FileDialogHelper*) (this=0x6440070, _pFileDlg=0x7631cc0) at sw/source/uibase/uiview/view2.cxx:2543 #9 0x00007fffde16b7e0 in SwView::LinkStubDialogClosedHdl(void*, sfx2::FileDialogHelper*) (instance=0x6440070, data=0x7631cc0) at sw/source/uibase/uiview/view2.cxx:2533 #10 0x00007ffff4985d98 in Link<sfx2::FileDialogHelper*, void>::Call(sfx2::FileDialogHelper*) const (this=0x87022a8, data=0x7631cc0) at include/tools/link.hxx:111 #11 0x00007ffff4b2bbf1 in sfx2::DocumentInserter::DialogClosedHdl(sfx2::FileDialogHelper*) (this=0x8702290) at sfx2/source/doc/docinsert.cxx:286 #12 0x00007ffff4b29fe0 in sfx2::DocumentInserter::LinkStubDialogClosedHdl(void*, sfx2::FileDialogHelper*) (instance=0x8702290, data=0x7631cc0) at sfx2/source/doc/docinsert.cxx:185
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ba20c2b1874cac08e93c3a122c8723868a29e456 tdf#58518: add message in case of not text file with "Insert->File" in Writer It will be available in 7.1.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.
Since string freeze has already be done (see https://wiki.documentfoundation.org/ReleasePlan/7.0), it can't be backported to 7.0 branch.
I'm not near computer now, but shouldn't this Insert - File.. be renamed to Insert - Text File..?
(In reply to Timur from comment #19) > I'm not near computer now, but shouldn't this Insert - File.. be renamed to > Insert - Text File..? It is Insert > Text from File... and IIRC we change this recently as it was just "Text" (or File?).