Bug Hunting Session
Bug 94556 - Table borders do not reflect changes properly - refreshing problem?
Summary: Table borders do not reflect changes properly - refreshing problem?
Status: RESOLVED DUPLICATE of bug 85909
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.0.2.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-27 22:20 UTC by David
Modified: 2017-08-13 15:22 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Bottom Right Group of Cells (48.15 KB, application/vnd.oasis.opendocument.graphics)
2015-09-27 22:20 UTC, David
Details
Sample document for table border bug (16.28 KB, application/vnd.oasis.opendocument.presentation)
2015-11-06 10:39 UTC, bellgardt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David 2015-09-27 22:20:29 UTC
Created attachment 119078 [details]
Bottom Right Group of Cells

Things have definitely improved in this release but the issues still persist.

There seem to be two areas giving problems:

1. Refreshing of screen after border changes. I actually have to close LO then open the document again to see what border changes have been done.

2. Drawing borders around selected cell or cells still has issues.

Attached is a document with a table. Drawing borders worked correctly for the entire document EXCEPT the bottom right group of cells. I just don't seem to be able to replicate the same layout that I've used with the other groups of cells.

Get this sorted and *maybe* the buggy table border formatting bug will finally be sorted.
Comment 1 David 2015-09-27 22:29:58 UTC
Finally, after 30 mins of trial and error I managed to get the borders for the bottom right group of cells to match the rest of the document.

Solution:

1. Select only the top cell of the vertical group of three and turn on LEFT+RIGHT border.

2. & 3. Repeat for middle cell, and then for bottom cell.

4. Finally, select the three cells together as a group. Turn on Top and Bottom border.

Needless to say, after each step I had to close LO and reopen the document to see the updated changes.

Why did it work correctly for the other 35 or so groups of cells but not the last one?
Comment 2 Joel Madero 2015-09-28 00:55:50 UTC
Hi David -

As to why - who knows, millions of lines of code - bugs happen.

That being said, can you please describe the bug a bit clearer. Provide exact reproducible steps (describe them as if you're telling someone only moderately familiar with LibreOffice step by step how to reproduce the issue, what you expect, and what you actually observe).

Setting to NEEDINFO - once you clarify how to reproduce the issue, please set to UNCONFIRMED. Thanks

Examples of how to report a good bug report can be found at this link:
https://wiki.documentfoundation.org/QA/BugReport#Good_Reports
Comment 3 David 2015-09-28 01:03:05 UTC
Select the three cells vertically at the bottom right of the document.

Clicking the border button for the table should give you a pop-up with all the border possibilities.

Select the one with an outside border on all four sides.

The correct result of this action should be that a border appears around the group of three.

What you get is individual borders around each of the selected cells in that group. 

That behaviour is wrong. The border is being added to a group object not individual cells in that group.

And if you are really unlucky you will not even seen a change because there is another bug which sometimes requires you to close the document and reopen it to refresh the display.

I'm not sure I can explain it any more simply than that. A search through bugs for LO shows these bugs have been present a long time and while they have been improved, they have not yet been closed.
Comment 4 Cor Nouws 2015-09-28 08:30:03 UTC
(set this to Impress - there are quite some wishes/bug about tables in Impress/Draw.)
Comment 5 Buovjaga 2015-10-01 11:42:17 UTC
(In reply to David from comment #3)
> The correct result of this action should be that a border appears around the
> group of three.

I get this correct result.

Win 7 Pro 64-bit, Version: 5.0.2.2 (x64)
Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe
Locale: fi-FI (fi_FI)
Comment 6 bellgardt 2015-11-06 10:37:20 UTC
This bug drove me crazy already many times. I can confirm the strange behavior described by David with LO 5.0.2.2 (32bit) on win7 enterprise (64bit). But also something happens that seems not to be reproducible. For example: I changed the border style of certain cells and closed that dialog - the table still showed the old style. Then clicked outside of the table to deselect it and selected it again by mouse click -> the correct style appeared. In that session I could do this repeatedly, but afterwards never again. Another example: I changed the border style of some cells - nothing happened as above. Then changed the border style of same cells again to other settings and closed the dialog: the style just set before appeared. In that session I also could repeat this several times, but not afterwards.

I also found the following: After creating a new table everything works fine. But if you copy that table and begin to change the border styles of the copy it has the problems of this bug. These problems also start with the freshly created table after saving and reopening the file.

There is another point: In the table dialog it is also possible to select diagonal lines for cells and to set their style. But it seems this doesn't work at all. 

Interestingly, that little window in the border dialog where you select the borders to be changed (I'll call it "preview") mostly shows the correct borders (including diagonal lines) even if they didn't yet appear in the table itself. So it seems to me that the border properties are stored in different locations of the code and not all code parts access the same location.

Also there are some indifferent states in the table or in the preview. In my attachment please select cells the four cells 1.1 to 2.2 of table 1 and open the border dialog. The left, top and horizontal middle lines are shown correctly. The bottom line is grayed because the bottom borders of those two cells have different style. But the remaining vertical lines are also grayed although those borders have identical style. I think this is wrong.

If you select the cells 1.1 to 2.2 in table 2 the middle horizontal line is also grayed although the red border is identical in columns 1 and 2. Even if you select cells 1.3 and 2.3 the only green middle border is grayed! This seems to be another bug.

The border dialog also has a general usability problem if you want to change the style of selected borders only, e.g. in my sample table 1 for the green border: how can you change the thickness only or the color only? Now there is no way because if you select the border line in the preview it will become a thin black line at once and yo must set both, color and width again. But what color was it before and which thickness? You have no way to find that out. Therefore, In the preview it should be possible to make a pure selection of a border which copies the border attributes to the line attribute fields which can then be changed one by one. My suggestion is: the first click in a border line in the preview should only select that border and copy its attributes to the field on the right side. The first click should not at once apply the more or less arbitrary values of the attribute field to the selected border. Instead of "first click" there could be other ways to make a pure selection, eg. mouse pointer stays longer over a border line, or shift click, or right click.

Greetings, Karl
Comment 7 bellgardt 2015-11-06 10:39:09 UTC
Created attachment 120318 [details]
Sample document for table border bug
Comment 8 Buovjaga 2015-11-06 11:40:35 UTC
NEW per comment 6. Additional testing encouraged.
Comment 9 Cor Nouws 2015-11-07 10:17:54 UTC
(In reply to bellgardt from comment #6)
> This bug drove me crazy already many times. I can confirm the strange

I saw yesterday that it is enough to move the table a bit, to make changes show up. So looks a refreshment problem?
No reason to set this to minor, I think.. 

Any ideas how this was in older versions?
Comment 10 Buovjaga 2015-11-07 10:35:16 UTC
(In reply to Cor Nouws from comment #9)
> No reason to set this to minor, I think.. 

Can be seen as minor according to our evil system:
https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Comment 11 Cor Nouws 2015-11-07 11:02:45 UTC
(In reply to Beluga from comment #10)
> (In reply to Cor Nouws from comment #9)
> > No reason to set this to minor, I think.. 
> 
> Can be seen as minor according to our evil system:
> https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.
> jpg

Hmm, could well be. But IMO if average users change a border setting and the change is not visible, that's utterly annoying and a big minus for the user experience. So if it's clear how to reproduce reliable and simple (I'm not going to try that, sorry, time over..) I'd rather set it to major ;)
Comment 12 Buovjaga 2015-11-07 11:06:18 UTC
(In reply to Cor Nouws from comment #11)
> (In reply to Beluga from comment #10)
> > (In reply to Cor Nouws from comment #9)
> > > No reason to set this to minor, I think.. 
> > 
> > Can be seen as minor according to our evil system:
> > https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.
> > jpg
> 
> Hmm, could well be. But IMO if average users change a border setting and the
> change is not visible, that's utterly annoying and a big minus for the user
> experience. So if it's clear how to reproduce reliable and simple (I'm not
> going to try that, sorry, time over..) I'd rather set it to major ;)

I'd rather treat the level of annoyance with priority. Severity describes the sheer horror (crashing, data loss) or triviality (some element not rendered immediately) of the situation.
Comment 13 David 2015-11-07 19:16:54 UTC
While bugs like these seem trivial the frustration they cause can be significant. When I encountered problems with table cell borders yet *again* I was almost ready to give up on LO.

LO has advanced into such a wonderful, mature application suite yet we are still plagued by "trivial* bugs that never seem to get fixed. They do affect usability and to such a degree that it makes the software questionable for serious office work.

LO should do the simple things well. They're the things everyone expects an office suite to do and do properly so NO these annoying little bugs are not trivial. They need to get sorted out once and for all *before* new features are added.
Comment 14 Cor Nouws 2015-11-07 20:39:15 UTC
(In reply to Beluga from comment #12)

> I'd rather treat the level of annoyance with priority. Severity describes
> the sheer horror (crashing, data loss) or triviality (some element not
> rendered immediately) of the situation.

Sounds logic.
But could it be that priority is related to developer engagement?
Comment 15 Cor Nouws 2015-11-07 20:42:23 UTC
(In reply to David from comment #13)
> While bugs like these seem trivial the frustration they cause can be
> [...]
> LO should do the simple things well. They're the things everyone expects an
> office suite to do and do properly so NO these annoying little bugs are not
> trivial. They need to get sorted out once and for all *before* new features
> are added.

I only can agree - any helping hand on any area is useful :)
Comment 16 David 2015-11-07 20:53:37 UTC
Yes, it is all about developer engagement. Unfortunately, many bugs only show themselves in specific appearance conditions to they don't affect many people. Only easily reproducible bugs affecting lots of users can be targeted effectively.

Still, it is important to keep posting bug reports in the hope that they get sorted. IMO, frustrating bugs that are present across multiple versions of LO (and perhaps present for years) should be targeted as high priority.

I have had so many clients give up on LO because simple things that are taken for granted in M$ Office fail to work properly here. Many of these issues are present even in the so-called "stable" LO releases.

Tables and table borders are one area where the code base needs a complete overhaul.
Comment 17 Joel Madero 2015-11-07 21:52:37 UTC
> 
> LO should do the simple things well. They're the things everyone expects an
> office suite to do and do properly so NO these annoying little bugs are not
> trivial. They need to get sorted out once and for all *before* new features
> are added.

This is not how the project works - the non-contributors *do not* dictate when *volunteers* fix bugs (or add feature). With that I'm removing myself from this conversation.
Comment 18 David 2015-11-07 22:00:21 UTC
Wow, comments like that kill participation. All I can say is what a jerk.

How about I stop contributing my time testing and reporting bugs since my participation clearly isn't as meaningful as yours.
Comment 19 Cor Nouws 2015-11-07 22:51:41 UTC
(In reply to Beluga from comment #10)
> (In reply to Cor Nouws from comment #9)
> > No reason to set this to minor, I think.. 
> 
> Can be seen as minor according to our evil system:
> https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.
> jpg

I read "does the bug involve a serious glitch"
So this flow chart results in setting Severity to Major?
Comment 20 Cor Nouws 2015-11-07 22:54:14 UTC
(In reply to Cor Nouws from comment #15)
> (In reply to David from comment #13)
> > While bugs like these seem trivial the frustration they cause can be
> > [...]
> > LO should do the simple things well. They're the things everyone expects an
> > office suite to do and do properly so NO these annoying little bugs are not
> > trivial. They need to get sorted out once and for all *before* new features
> > are added.
> 
> I only can agree - any helping hand on any area is useful :)

Sorry, have to withdraw my support here.
I meant to support that it's annoying needs attention etc usw.
But I did skip reading the end. And it is no option (for multiple reasons) that bugs get "sorted out once and for all *before* new features are added."
That really is impossible and not going to work.
Sorry for the confusion. 
Cor
Comment 21 Cor Nouws 2015-11-07 22:55:47 UTC
(In reply to David from comment #16)
> Yes, it is all about developer engagement. Unfortunately, many bugs only
...

not to forget clear and good triaged issues, bibisecting, and finished easy hacks.. ;)
Comment 22 Joel Madero 2015-11-08 02:36:44 UTC
(In reply to David from comment #18)
> Wow, comments like that kill participation. All I can say is what a jerk.
> 
> How about I stop contributing my time testing and reporting bugs since my
> participation clearly isn't as meaningful as yours.

Just to clarify - I'm not a developer either and thus, when I report bugs (which I've reported quite a few), I don't say "this needs to get fixed" as it's not my time that is needed to fix it. If a volunteer tackles it one day, awesome, else, I'll wait patiently and continue doing my part to make the project better (reporting, triaging, etc... etc...). If that makes me a jerk, I suppose I can accept that.

Anywho, I wasn't trying to pick a fight or take the subject off topic, I was just trying to keep expectations realistic. If you're unhappy with volunteer developers tackling bugs as they please (and adding features as they please), then yes, I suppose this isn't the project for you
Comment 23 bellgardt 2015-11-09 07:32:43 UTC
> Any ideas how this was in older versions?

This bug existed already in version 2.
Comment 24 Buovjaga 2015-11-09 07:54:46 UTC
(In reply to bellgardt from comment #23)
> > Any ideas how this was in older versions?
> 
> This bug existed already in version 2.

Do you mean OpenOffice.org version 2.0?
Comment 25 Joel Madero 2015-11-09 16:45:27 UTC
Updating version per the second to last comment - assuming that means OOo 2.0 which means this was inherited.

Version field is the oldest version that the bug shows itself, not the latest tested on. This eliminates the chance that it's a regression, no way to bibisect it, nothing else for QA to do really. On a volunteer developer to tackle it at this point. To me this is a minor bug by definition (maybe minor - high to reflect the annoying nature of it) but I don't want to mess with it and cause any flame wars.
Comment 26 Cor Nouws 2015-11-09 19:12:34 UTC
(In reply to Joel Madero from comment #25)
> Updating version per the second to last comment - assuming that means OOo
> 2.0 which means this was inherited.


In LO 3.3.0 changes in borders show up immediately...
Comment 27 bellgardt 2015-11-10 09:41:35 UTC
(In reply to Joel Madero from comment #25)
> Updating version per the second to last comment - assuming that means OOo
> 2.0 which means this was inherited.

Sorry, I am not quite sure what was the exact problem in OOo 2, because for a long time I didn't use the build-in tables in Impress but only work-arounds. 

I checked it again with LO 3.4 and found - same as Cor - the border update is working. But the border dialog has more problems there: After opening the dialog, that border preview window doesn't show any actual border style at all. So, the usability problem described in my comment 6 became a bit less serious in LO 5 than before. 

On the other hand, the line style selection in LO 3.4 has many choices (solid, dashed ...), while in LO 5 only solid and empty are available.
Comment 28 QA Administrators 2017-01-03 19:35:27 UTC Comment hidden (obsolete)
Comment 29 Regina Henschel 2017-08-13 15:22:26 UTC
There are a lot of bug reports about problems with borders. I have chosen bug 85909 as "active" bug and set the others to duplicate. Please continue there.

*** This bug has been marked as a duplicate of bug 85909 ***