Description: Seen on 7.0.2.2 on Mac when inserting a cover image on the first page. If the image was larger than the page less margins, I got the Spinning Beachball of Death. Setting the page borders to zero stopped this happening. Inserting the image then warned that the image was larger than the printable area, which is OK. I made a 20.5x29cm image in Gimp. A4 is 21x29.7cm. Steps to Reproduce: 1. Make A4 document with 2cm margins. 2. Make 20.5cm x 29cm image 3. Insert image Actual Results: Writer hung and needed Force Quit. Repeated quite a few times. Fixed by changing page margins. I could then stretch the image to the actual page boundaries. Expected Results: Insert image somehow. Not to hang. Reproducible: Always User Profile Reset: No Additional Info: Warn, with option to crop the page to the page limits or abort.
Please attach both image and writer document needed to reproduce this problem.
Created attachment 166931 [details] Document to demonstrate bug This is a heavily cut down version of my problem document. It still shows the problem on my machine. Problem image follows. Pasting the image in the first page with 2 cm margins causes the hang. Take out the margins and it is OK.
Created attachment 166932 [details] Image for ImageCrash scene Image for ImageCrash scene. Hangs pretty reliably on my machine.
[Automated Action] NeedInfo-To-Unconfirmed
no repro in Version: 7.1.0.0.alpha1+ Build ID: 7dc234fa57ca409d0db131c93abea738014b5e1f CPU threads: 4; OS: Mac OS X 10.15.7; UI render: default; VCL: osx Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded any size image just resizes for current margins
(In reply to Roman Kuznetsov from comment #5) > no repro in > > Version: 7.1.0.0.alpha1+ > Build ID: 7dc234fa57ca409d0db131c93abea738014b5e1f > CPU threads: 4; OS: Mac OS X 10.15.7; UI render: default; VCL: osx > Locale: ru-RU (ru_RU.UTF-8); UI: en-US > Calc: threaded > > any size image just resizes for current margins Weird. I have just repeated it to check. Well, you can't fix what you can't see. I will post if I have any new info. Thanks.
Just done a fresh install of 7.0.3, Flushed out all user preferences. Test as supplied still hangs my machine. If I make a new document with the same page style, I can paste the image and there are no problems. So, there is something in the test document that locks things up. I have tried re-applying the default Page Style but this does not clear it. Unfortunately for me, the ImageCrash scene is a cut down version of a 225-page document.
I have a workaround... Create a new document. Select all the contents of the old document. Copy and paste everything into the new document. Save. Pasting image no longer hangs Writer with the new copy. Not a bug fix but we can probably drop the importance right down.
Can be reproduced with attached files video example: https://streamable.com/0i3vmq Version: 7.1.4.2 (x64) / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 6; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
upd actual video link: https://streamable.com/t8g2l4
No repro 6.4-, repro 6.4+ (crash in 7.0 oldest in GTK3, hang in 7.0 master) and still in 7.4+.
Lin 64 commit d250ca91c79f457102daf4da81446b7f130fb0ee Date: Fri Dec 6 01:56:32 2019 +0100 source d0aa2dbdf37aefe5b8d096fc5ea50cd13f87c5b0 pre source f96f290c1988d7bfbe439470281d946d6f5add65 author Miklos Vajna <vmiklos@collabora.com> sw: insert image: set anchor to at-char by default This changes the default set in commit 4f40bf6a79de6d60da0a5090cdfeda6242e889f0 (sw: insert image: set anchor to as-char by default, 2019-07-04), to have a better compromise, taking both Word defaults compatibility and usability into account. The problem is that users are used to just inserting an image and being able to drag it to its final location, which is broken with as-char anchoring. So default to at-char anchoring, this is still something that is fully interoperable to Word (unlike the old to-para anchoring), but allows the easier image move again. (cherry picked from commit a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db) CC: Miklos, please see.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3e9975cf507e24e9c501575c501833164d217acc tdf#137920 sw: avoid layout loop when inserting at-char anchored large image 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/1a9147b86bb8f06efd1275b2025cd7f464e0331d tdf#137920 sw: avoid layout loop when inserting at-char anchored large image It will be available in 7.3.1. 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.
Verified. Thanks.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/04b4c269fc2e4001eb37c4b2c34a023a44ca6ebe tdf#137920 sw: avoid layout loop when inserting at-char anchored large image It will be available in 7.2.6. 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.