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?

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

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.

(set this to Impress - there are quite some wishes/bug about tables in Impress/Draw.)

(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)

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

Created attachment 120318 [details]
Sample document for table border bug

NEW per comment 6. Additional testing encouraged.

(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?

(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

(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 ;)

(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.

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.

(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?

(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 :)

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.

> 
> 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.

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.

(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?

(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

(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.. ;)

(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

> Any ideas how this was in older versions?

This bug existed already in version 2.

(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?

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.

(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...

(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.

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 ***