Bug 64498 - EDITING: Border changes not applied if one does not click inside table in Impress
Summary: EDITING: Border changes not applied if one does not click inside table in Imp...
Status: RESOLVED DUPLICATE of bug 85909
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
: 85735 (view as bug list)
Depends on:
Reported: 2013-05-12 15:59 UTC by Milan Bouchet-Valat
Modified: 2017-08-13 15:04 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Presentation with a simple table to reproduce the bug (10.53 KB, application/vnd.oasis.opendocument.presentation)
2013-05-12 15:59 UTC, Milan Bouchet-Valat

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Bouchet-Valat 2013-05-12 15:59:41 UTC
Created attachment 79198 [details]
Presentation with a simple table to reproduce the bug

Selecting all cells in the table from the attached presentation and trying to add black borders (e.g. the top border) does not work if one does not click inside the table after clicking OK. Clicking outside of the table in an empty area results in no border being added at all.

This is reproducible with any presentation, be it simple or complex, not only with the attached example. If you do not select the whole table but only a few cells, you can get weirder behaviours, like some grey borders being added and others not.

(In any case, there is another probably related issue: even if you click on the table so that the border appears, it is not reflected in the Cells formatting dialog.)

This behaviour feels completely non-deterministic to any user except fools like me who try one hundred times until they get the desired result. This is very frustrating until you get the workaround (clicking inside the table). For most users, borders will feel broken, period.
Comment 1 ign_christian 2013-05-14 14:31:49 UTC
Confirmed same behavior on LO  with Win7 Home Premium 32bit
Comment 2 tommy27 2014-06-15 07:24:42 UTC
original report filed with "Linux" platform, later confirmed on Windows as well, hence platform is "All"

works fine with LibO and fails with subsequent releases including and Build ID: 81d2c208a4e6f9df87e2ee70c6e6da146742178a
TinderBox: Win-x86@42, Branch:master, Time: 2014-06-10_23:52:11

very annoying and frustrating regression. I agree finding the workaround is not intuitive
Comment 3 Matthew Francis 2014-12-04 15:05:37 UTC
Results from bibisect-43all:
Not sure if this is precisely the original incarnation of the bug, as the commit appears to be much later than the report, but the below appears to be a valid boundary from working -> not working for changing the table borders, so perhaps this is a recurring regression

The first bad commit could be any of: 524032d94d92022e87e0add99aea74683da8f368 f832455cd2cc194ff04197ef174cb1e658336d18 1b831d02ff29aa5763cf33ae75131f98d882201f
We cannot bisect more!

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [c2069a369d738078124812312d51f21ea1ce2421] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0
git bisect start 'latest' 'last41onmaster'
# good: [33ac6698e6d90d84f99d784b9553ee87eec27d6a] source-hash-732c0f929fc0229b6da37d4ec4b6de8994fcea46
git bisect good 33ac6698e6d90d84f99d784b9553ee87eec27d6a
# good: [0b79394752f7ecbab6ab4ecedbfab8551c6e9fbd] source-hash-381613916d42a1e18e2824b5d41028dcfe19659a
git bisect good 0b79394752f7ecbab6ab4ecedbfab8551c6e9fbd
# skip: [d50b7ec6c36fecb4ff94243754027d7c4e63af9e] source-hash-7328e577e297924ba9cdfc2498f84b1d17d603d4
git bisect skip d50b7ec6c36fecb4ff94243754027d7c4e63af9e
# bad: [882db5e268e28962bdf805c820a5e031b0df9936] source-hash-383dccc094f8c8c07b4298ce0b7406d18cd61cee
git bisect bad 882db5e268e28962bdf805c820a5e031b0df9936
# bad: [6feabb3ce67846b727583754afd4380ec7d59f13] source-hash-874a9b46cb54e4c05e262e5d7490790a08ea0c55
git bisect bad 6feabb3ce67846b727583754afd4380ec7d59f13
# skip: [524032d94d92022e87e0add99aea74683da8f368] source-hash-c7363cb6d1d31f2a7d40a76e62b5934629a1a8a1
git bisect skip 524032d94d92022e87e0add99aea74683da8f368
# skip: [f832455cd2cc194ff04197ef174cb1e658336d18] source-hash-a79afdaa11a1af26c9404441dcf27ef197e972b2
git bisect skip f832455cd2cc194ff04197ef174cb1e658336d18
# good: [bfba063779a12bca219e4a9fba9bba8b67821ec1] source-hash-86a32589e90ee983159fb5b2c6a594428ab7d422
git bisect good bfba063779a12bca219e4a9fba9bba8b67821ec1
# skip: [b8faa3ecebb63b814ada4be4917f2ea81f97907d] source-hash-7a120ad4ac99ac70c35132d12d11d630b92bd846
git bisect skip b8faa3ecebb63b814ada4be4917f2ea81f97907d
# skip: [422186458e0b4db00c7e26b54d5b631f83bcad2a] source-hash-6948bf58ce181b17f60ef81f10205ef4dac50cc6
git bisect skip 422186458e0b4db00c7e26b54d5b631f83bcad2a
# bad: [1b831d02ff29aa5763cf33ae75131f98d882201f] source-hash-b7c3e851465638d4416ca8837937946353561088
git bisect bad 1b831d02ff29aa5763cf33ae75131f98d882201f
# good: [5aabfb0ff009add636c42a60c05cc03bbf5cc1dd] source-hash-f2130cea98f6c9ce7c90207828f5d0c7ec3e4020
git bisect good 5aabfb0ff009add636c42a60c05cc03bbf5cc1dd
# good: [87bfccc81c2d8028642492b80505217d7b42a5a8] source-hash-5b4b6b2aad548cdc27ba2aa7d87ff584ec7e97dd
git bisect good 87bfccc81c2d8028642492b80505217d7b42a5a8
# only skipped commits left to test
# possible first bad commit: [1b831d02ff29aa5763cf33ae75131f98d882201f] source-hash-b7c3e851465638d4416ca8837937946353561088
# possible first bad commit: [f832455cd2cc194ff04197ef174cb1e658336d18] source-hash-a79afdaa11a1af26c9404441dcf27ef197e972b2
# possible first bad commit: [524032d94d92022e87e0add99aea74683da8f368] source-hash-c7363cb6d1d31f2a7d40a76e62b5934629a1a8a1
Comment 4 Matthew Francis 2015-01-14 13:16:47 UTC
*** Bug 85735 has been marked as a duplicate of this bug. ***
Comment 5 Matthew Francis 2015-01-14 13:18:03 UTC
(Investigation results moved from duplicate bug 85735)

The behaviour seems to have changed at the below commit.

Adding a Cc: to l.lunak@collabora.com; Could you possibly take a look at this? Thanks

commit 26b06662ebc3e5d664400bc95c39d6220de03136
Author: Luboš Luňák <l.lunak@collabora.com>
Date:   Tue Mar 25 11:27:51 2014 +0100

    avoid repeated table layouting (fdo#75622)
    With the document from fdo#75622, this saves 3775 calls and leaves only 13.
    e586fe4585dc07e6f6dd061d09f6a7fb0b22948c removed avoiding the call
    to LayoutTable(), which made loading slow. I checked that the doc from that
    bugreport still works, so if very original code was correct in avoiding
    the call sometimes, this should be ok too.
    Change-Id: Ia80f974d4497e5cb04612331527eb87b579ddb76
Comment 6 Robinson Tryon (qubit) 2015-12-13 11:09:31 UTC Comment hidden (obsolete)
Comment 7 Milan Bouchet-Valat 2017-02-06 10:23:07 UTC
Still happens with Please do not close bugs without giving details on where it works.
Comment 8 Buovjaga 2017-02-11 17:04:01 UTC
Clicking inside the table after OKing border changes does not make the borders appear for me. I just investigated bug 85436 and a duplicate.

Arch Linux 64-bit, KDE Plasma 5
Build ID: ac8197327d3ef4f3c94fb0746393863404df086b
CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on February 11th 2016
Comment 9 Regina Henschel 2017-08-13 15:04:26 UTC
There exists a lot of bug reports about not working border changes. I take bug 85909 as "active" bug and will mark the others as "duplicate".

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