Description: When inserting an image into the page header in Writer, if the image is too tall to fit on the page, an infinite number of pages start to be added. I see the page count in the bottom-left of the UI increasing indefinitely. Steps to Reproduce: 1. Add a page header to a new document. 2. Insert > Image, and select a tall image from the filesystem. 3. Click 'Open' Actual Results: Page count increases in an infinite loop. Can be ended by hitting backspace. Expected Results: Not sure! Perhaps: - a UI warning after 1000 pages, followed by an undo of the insert? - allowing text to flow over the image if it's too tall - something else Reproducible: Always User Profile Reset: No Additional Info: It appears that the text is pushed off the end of the page, but because the header image is included on *every* page, Writer can't find an empty page to flow the text onto.
Created attachment 148485 [details] A red rectangle 900px high
Created attachment 148486 [details] Document to reproduce problem
Reproducible with Version: 6.1.4.2 (x64) Build-ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group threaded If you add the image to an empty document, the bug doesn't occur. So the problem is, that there is noch space for the text. Additional information: If you add it to the footer, the bug doesn't occur, but the image covers the text. Solutions? I don't know. Let's ask design team.
Created attachment 148488 [details] A second document that can be triggered by shorter images This second document demonstrates how basically the same bug can be triggered by a shorter image, if there is a page with content that cannot be reflowed.
Created attachment 148489 [details] A shorter red rectangle
Possibly related based on the description: - bug #38575 - bug #89150
If the question for UX is what to do with badly sized images we could a) accept the input (and make sure the page count is not affected), b) scale to fit into the actual header (which makes it consequently impossible to exceed the page size on resizing), or c) crop the image. I would prefer a) over b) and refuse c). Eventually it looks like a serious bug, raising the importance.
(In reply to Heiko Tietze from comment #7) > If the question for UX is what to do with badly sized images we could > a) accept the input (and make sure the page count is not affected), > b) scale to fit into the actual header (which makes it consequently > impossible to exceed the page size on resizing), or > c) crop the image. > I would prefer a) over b) and refuse c). Given the second test case, where a much smaller image can trigger the same behaviour, I think it will be difficult to determine whether an image is "badly sized". My hunch is that the bug lies in the fact that text reflowing is triggered at all, perhaps... I guess I find it unexpected that a header image can sit outside of the header area and cause text in the body to wrap around it. UX-wise, I'd expect consistency between headers and footers, but I haven't confirmed for myself how the footer behaviour differs.
Reproduced with LO 6.2.8 and Lo 6.3.3 but not with master 6.5+. Inserted image is small and header-size, regardless it's original size. Closing as WorksForMe.