Bug Hunting Session
Bug 80345 - HTML Document: default table styles vertical borders not rendered visibly
Summary: HTML Document: default table styles vertical borders not rendered visibly
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer Web (show other bugs)
Version:
(earliest affected)
4.2.5.2 release
Hardware: All All
: high minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Table-Borders
  Show dependency treegraph
 
Reported: 2014-06-22 03:39 UTC by Kevin Suo
Modified: 2019-06-06 02:53 UTC (History)
11 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 Kevin Suo 2014-06-22 03:39:30 UTC
This bug is a "clone" of bug 80292. In that bug I found that when create a HTML document in libreoffice and insert a table, it's always a "one-column" table. But after further investigation, I find it's not "one-column", it's many columns as expected but without left and right borders so it looks like one-column.

Steps:
1. Start LibreOffice;
2. File - New - HTML Document;
3. Table - Insert - Table:  8 rows 8 columns

Current Result:

A table with 8 rows and 8 columns was inserted, but there is no left and right borders for the cells. 
When save the file and view HTML source, I see the following for each <td> tag:

<td width="13%" ... border-right: none;...>

So maybe the "border-right: none" caused the problem.
When you insert a table, it should never by default to set top-bottom borders to 1px but left-right borders to none.

Reproduce with: 
4.2.5.2, 4.3.0.1
Ubuntu 14.04 x86
Comment 1 Kevin Suo 2014-06-22 03:48:16 UTC
Added the cc list in bug 80292 to this one.
Comment 2 Yousuf Philips (jay) (retired) 2014-06-24 07:01:24 UTC
Confirmed in Linux Mint in 4.0.6, 4.1.6, 4.2.5 and 4.3.0. Worked correctly in 3.3.0 and 3.6.7. The table is not visible at all in 4.0 and 4.1, while in 4.2 and above, the left and right borders of each cell are missing. Included below is the html code of the first cell in various versions.

= LibO 3.3 =

<TD WIDTH=13% STYLE="; border-top: 2.60pt double #808080; border-bottom: 2.60pt double #808080; border-left: 2.60pt double #808080; border-right: none; padding-top: 0.04in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in">

= LibO 3.6 =

<TD WIDTH=13% STYLE="border-top: 1px double #808080; border-bottom: 1px double #808080; border-left: 1px double #808080; border-right: none; padding-top: 0.04in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in">

= LibO 4.0 to 4.3 =

<td width="13%" style="border-top: 1px double #808080; border-bottom: 1px double #808080; border-left: 1px double #808080; border-right: none; padding-top: 0.04in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in">

So after looking over this html code, it seems there is nothing wrong with the html code, its just that LibO is not rendering it properly, as opening the 4.0 html file in 4.2 shows the top and bottom borders.
Comment 3 Caolán McNamara 2014-06-24 12:39:07 UTC
I believe the problem is just the rendering of the line style of the table.

Go to table->table properties->borders and change the "Style" of the line from the fourth-last to the second entry and it renders well, back to the fourth-last and the vertical lines disappear
Comment 4 Yousuf Philips (jay) (retired) 2014-06-24 20:24:59 UTC
Yes that will do fix it, but LibO should be setting these things incorrectly.
Comment 5 Joel Madero 2014-07-09 05:02:35 UTC
Priority:
Minor - slows down professional quality work but does not prevent it
High - regression + easily visible


221bf5c0db153e24c67ff29fe614af7cc010a356 is the first bad commit
commit 221bf5c0db153e24c67ff29fe614af7cc010a356
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Tue Dec 11 04:33:50 2012 +0000

    source-hash-9210b95bcfd65ae558f445666d9b880e794d4c74
    
    commit 9210b95bcfd65ae558f445666d9b880e794d4c74
    Author:     Kohei Yoshida <kohei.yoshida@gmail.com>
    AuthorDate: Thu Nov 15 16:31:49 2012 -0500
    Commit:     Kohei Yoshida <kohei.yoshida@gmail.com>
    CommitDate: Thu Nov 15 18:07:17 2012 -0500
    
        Make GetParent() const-correct.
    
        const method should return const pointer if it points to an object held
        internally & prefer taking const pointer as a method argument if possible.
    
        Change-Id: I4dc8c31d55aa0054ea6db521be9ad45fefef8d07

:100644 100644 738578ee72c5b929f6609df9971137caf4a49dd2 26157d38356b3591abc92ee949953d37ac93201f M	autogen.log
:100644 100644 5f2a44c5e7ce0c7653b5834e1f4a329791243ae2 5f3674b08eed2ed4a5a89db302b5a9c11e5cc33e M	ccache.log
:100644 100644 e1b88a7fa01b6f2a281894d7f6849ab2330aab76 1b372eb248c5d4846b8e34b67c97c86ee2137d7a M	commitmsg
:100644 100644 33209181930196bebdc405c8ca66e9169724b348 fe6de78bab06d66b4dcc7daf3e8da0a9bd028bcd M	dev-install.log
:100644 100644 1260d21415e7d260c7b6a1ca81cde42fee4ecbaa 15080cbc9084e133603b9c0a387bc9f590c8e05b M	make.log
:040000 040000 fa33c45cc461aca44e2b41f25b965b8dc089ba34 af9223892695b7550d228ad3a89f09d98ffb9e44 M	opt

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327
# bad: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e
git bisect bad 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02
# good: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10
git bisect good 51b63dca7427db64929ae1885d7cf1cc7eb0ba28
# bad: [d65a58c31c8da044ef66ae4517fa2fe74cec0019] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af
git bisect bad d65a58c31c8da044ef66ae4517fa2fe74cec0019
# bad: [79e02001f27d33b3b478324ab6fba5683413b4d9] source-hash-b6c016da23d309b4ac7d154bc33a22397974ed73
git bisect bad 79e02001f27d33b3b478324ab6fba5683413b4d9
# good: [183a576d94de9a9439d580c8b81f335ab57cdbdc] source-hash-a599f5b4b51848e3b397d471c9d12b373caadcef
git bisect good 183a576d94de9a9439d580c8b81f335ab57cdbdc
# good: [a67b874d60de1f1a44bef57a53a7b8a84db0ba58] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7
git bisect good a67b874d60de1f1a44bef57a53a7b8a84db0ba58
# bad: [221bf5c0db153e24c67ff29fe614af7cc010a356] source-hash-9210b95bcfd65ae558f445666d9b880e794d4c74
git bisect bad 221bf5c0db153e24c67ff29fe614af7cc010a356
# good: [46f9a799a00ba869957d7aa7650cae7fd2501394] source-hash-a43a76cd5aa2f145f2cb43fcdbc8f21fb6c89af0
git bisect good 46f9a799a00ba869957d7aa7650cae7fd2501394
# first bad commit: [221bf5c0db153e24c67ff29fe614af7cc010a356] source-hash-9210b95bcfd65ae558f445666d9b880e794d4c74
Comment 6 QA Administrators 2015-07-18 17:44:31 UTC Comment hidden (obsolete)
Comment 7 Robinson Tryon (qubit) 2015-12-13 11:10:51 UTC Comment hidden (obsolete)
Comment 8 Xisco Faulí 2016-10-07 12:15:06 UTC
Regression introduced by

author	Kohei Yoshida <kohei.yoshida@collabora.com>	2014-03-03 22:58:11 (GMT)
committer	Kohei Yoshida <kohei.yoshida@collabora.com>	2014-03-05 03:02:37 (GMT)
commit	2c62596cf264ef10749d8bfdb2bb2ebef2d98fbc (patch)
tree	1311156cb36884d0dde2b022467d7d0de6d799df
parent	fb052ae6174e4c96157ef6973f02c1d3cd4d9ba2 (diff)

fdo#75260: Correctly draw double lines for both Writer and Calc.

Fix all sorts of incorrect double line handling in drawinglayer in order to
draw thick-thin double line types correctly.  Also change handling of border
lines in writer tables. There are still some outstanding issues but it's
much better than how it was before.

Also realized that Word and Excel handle simple thin double lines differently;
Word varies widths of all of the lines and the gap whereas Excel only has one
fixed size for its double line.  For this reason I decided to add

Adding Cc: to Kohei Yoshida
Comment 9 Telesto 2017-05-07 11:57:40 UTC
Still a repro with:
Version: 5.4.0.0.alpha1+
Build ID: 274ecb49b70b3f01d47546e3b44317946c106042
CPU threads: 4; OS: Windows 6.2; UI render: default; 
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-05_22:45:07
Locale: nl-BE (nl_NL); Calc: single
Comment 10 Telesto 2017-07-08 17:44:54 UTC
No repro with:
Version: 6.0.0.0.alpha0+
Build ID: cac5c9f6081590b0548d3116bc4cd4a2509ec576
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-07-01_00:41:48
Locale: it-IT (nl_NL); Calc: CL

Probably because of: https://cgit.freedesktop.org/libreoffice/core/commit/?id=74d9b711d71cbaf4f853559211f6525db4a4b5db
Comment 11 QA Administrators 2019-06-06 02:53:54 UTC
Dear Kevin Suo,

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