Bug Hunting Session
Bug 122862 - Inserting an image into header causes pages to be added in an infinite loop
Summary: Inserting an image into header causes pages to be added in an infinite loop
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.7.2 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, possibleRegression
Depends on:
Blocks: Writer-Header-Footer
  Show dependency treegraph
 
Reported: 2019-01-21 16:22 UTC by Tim Retout
Modified: 2019-02-05 17:34 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
A red rectangle 900px high (3.36 KB, image/png)
2019-01-21 16:23 UTC, Tim Retout
Details
Document to reproduce problem (10.95 KB, application/vnd.oasis.opendocument.text)
2019-01-21 16:26 UTC, Tim Retout
Details
A second document that can be triggered by shorter images (14.72 KB, application/vnd.oasis.opendocument.text)
2019-01-21 16:59 UTC, Tim Retout
Details
A shorter red rectangle (875 bytes, image/png)
2019-01-21 17:00 UTC, Tim Retout
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Retout 2019-01-21 16:22:00 UTC
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.
Comment 1 Tim Retout 2019-01-21 16:23:23 UTC
Created attachment 148485 [details]
A red rectangle 900px high
Comment 2 Tim Retout 2019-01-21 16:26:41 UTC
Created attachment 148486 [details]
Document to reproduce problem
Comment 3 Dieter Praas 2019-01-21 16:47:09 UTC
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.
Comment 4 Tim Retout 2019-01-21 16:59:03 UTC
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.
Comment 5 Tim Retout 2019-01-21 17:00:01 UTC
Created attachment 148489 [details]
A shorter red rectangle
Comment 6 Tim Retout 2019-01-21 17:20:39 UTC
Possibly related based on the description:

- bug #38575
- bug #89150
Comment 7 Heiko Tietze 2019-01-21 19:57:23 UTC
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.
Comment 8 Tim Retout 2019-01-21 23:47:19 UTC
(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.