Bug 96105 - Writer in HTML mode does not handle PageFill correctly
Summary: Writer in HTML mode does not handle PageFill correctly
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha1
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: (X)HTML-Export
  Show dependency treegraph
 
Reported: 2015-11-27 16:35 UTC by Armin Le Grand
Modified: 2023-07-29 03:17 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Armin Le Grand 2015-11-27 16:35:44 UTC
Writer in HTML mode holds PageBackgroundFill not at the PageStyle 'Default Style' but in one called 'HTML'. This is probably not correctly used in the FillStyle fallbacks, e.g. the PageBackground FillStyle attributes shown when opening the dialog (context menu in Writer in HTML mode, Page...).

To reproduce:
- New Writer, set PageBackground using context menu, page...
- save as HTML
- File/Reload
- same dialog, bitmap fill is selected, but empty bitmap shown

P.S.: This task needs tdf#94088 be integrated, else the reload will lose the bitmap
Comment 1 Armin Le Grand 2015-11-27 16:35:55 UTC
grepping...
Comment 2 A (Andy) 2015-12-26 21:09:32 UTC
Buggy behaviour is reproducible with LO 5.1.0.1, Win 8.1

Steps I have done:
1. Open WRITER
2. Right mouse click -> PAGE -> tab AREA -> section FILL -> select Bitmap = Fiery (preview below shows a red coloured image instead of blue as in the icon -> another bug) and press OK
-> The page is filled with a red coloured image
3. Save the file as a html file
4. Close the file
5. Reopen the file
6. The page is filled blue, but not with the red coloured image (-> another bug) and it has two comments with "HTML:<meta name= ..." (-> another bug)

The page is filled (was actually filled with a bitmap) but in right mouse click -> PAGE -> tab AREA -> section FILL -> Bitmap = Blank is selected.

Besides the above mentioned lost bitmap, it is the strange for me why there two comments shown in LO with the the comments "HTML: <meta name="created" content=" TIME STAMP and "HTML: <meta name="changed" content=" TIME STAMP?
Comment 3 QA Administrators 2017-01-03 19:57:23 UTC Comment hidden (obsolete)
Comment 4 Xisco Faulí 2017-07-13 11:00:47 UTC
Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue
Comment 5 QA Administrators 2018-07-14 02:46:23 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2020-07-14 04:04:01 UTC Comment hidden (obsolete)
Comment 7 Stéphane Guillou (stragu) 2021-06-14 07:09:48 UTC
Only partial repro in:

Version: 7.2.0.0.alpha1+ / LibreOffice Community
Build ID: bb54d6d8241a06a6772052b77b67d6a4f686426c
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-11_20:14:38
Calc: threaded

To me, the real issue described here is that when there is a <body background=*> value in the HTML, it is assigned to a "HTML" page style rather than to the default "Default Page Style".
So isn't this a filter (i.e. HTML import) issue? Or am I missing something?

I don't think the issue with the right bitmap not being selected in the dialogue (Format > Page Style > Area) is actually a bug, as we can't expect LO to match the base64-encoded bitmap of the HTML file to the corresponding image in the LO gallery. The preview in the dialogue is correct.

I couldn't see any of the extra issues described in Comment 2.
Comment 8 QA Administrators 2023-07-29 03:17:55 UTC
Dear Armin Le Grand,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug