Description: When I select a table cell with border drawn, click on clone formatting and then select other table cells, these have no border, even if they had it before. Steps to Reproduce: 1. Click Insert -> Table -> Okay 2. Click on the Table and select a Table Design in the Property sidebar (e.g. orange cells with white borders) 3. Select an cell (so that it is entirely highlighted) 4. Click on Clone Formatting 5. Select some other cell (in the same row) (so that it is entirely highlighted). Actual Results: The cell to which the format is cloned looses its (white) borders. Expected Results: The format should not change because we clone the format to a cell that has already the same format. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 12; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Ubuntu package version: 4:7.5.2-0ubuntu1 Calc: threaded
On pc Debian x86-64 with master sources updated today, I could reproduce this. Miklos: perhaps a code pointer: #0 MergeItem_Impl(SfxItemPool*, unsigned short&, SfxPoolItem const**, SfxPoolItem const*, bool) (_pPool=0x557f10959fd0, rCount=@0x557f15d1f6d0: 132, ppFnd1=0x557f15dda5f8, pFnd2=0x557f109ab250, bIgnoreDefaults=true) at svl/source/items/itemset.cxx:1095 #1 0x00007fcbdfa6f52b in SfxItemSet::MergeValue(SfxPoolItem const&, bool) (this=0x557f15d1f6a0, rAttr=..., bIgnoreDefaults=true) at svl/source/items/itemset.cxx:1153 #2 0x00007fcbdea6cc66 in sdr::table::SvxTableController::MergeAttrFromSelectedCells(SfxItemSet&, bool) const (this=0x557f11ad16d0, rAttr=SfxItemSet of pool 0x557f10959fd0 with parent 0x0 and Which ranges: [(1000, 1012), (1014, 1035), (1048, 1058), (1069, 1095), (1167, 1176), (1236, 1241), (1242, 1244), (1245, 1245), (4008, 4027), (4028, 4060)] = {...}, bOnlyHardAttr=false) at svx/source/table/tablecontroller.cxx:2436 #3 0x00007fcbdea78e54 in sdr::table::SvxTableController::GetAttributes(SfxItemSet&, bool) const (this=0x557f11ad16d0, rTargetSet=SfxItemSet of pool 0x557f10959fd0 with parent 0x0 and Which ranges: [(1000, 1012), (1014, 1035), (1048, 1058), (1069, 1095), (1167, 1176), (1236, 1241), (1242, 1244), (1245, 1245), (4008, 4027), (4028, 4060)] = {...}, bOnlyHardAttr=false) at svx/source/table/tablecontroller.cxx:2777 #4 0x00007fcbde798a18 in SdrObjEditView::TakeFormatPaintBrush(std::shared_ptr<SfxItemSet>&) (this=0x557f10c10d60, rFormatSet=warning: RTTI symbol not found for class 'std::_Sp_counted_ptr_inplace<SfxItemSet, std::allocator<void>, (__gnu_cxx::_Lock_policy)2>' warning: RTTI symbol not found for class 'std::_Sp_counted_ptr_inplace<SfxItemSet, std::allocator<void>, (__gnu_cxx::_Lock_policy)2>' std::shared_ptr<SfxItemSet> (use count 1, weak count 0) = {...}) at svx/source/svdraw/svdedxv.cxx:2834 #5 0x00007fcbb9c9d654 in sd::FuFormatPaintBrush::DoExecute(SfxRequest&) (this=0x557f16056720, rReq=...) at sd/source/ui/func/fuformatpaintbrush.cxx:67 #6 0x00007fcbb9c9d538 in sd::FuFormatPaintBrush::Create(sd::ViewShell*, sd::Window*, sd::View*, SdDrawDocument*, SfxRequest&) (pViewSh=0x557f105b9b40, pWin=0x557f102fe940, pView=0x557f10c10d60, pDoc=0x557f1095abd0, rReq=...) at sd/source/ui/func/fuformatpaintbrush.cxx:53 #7 0x00007fcbba117ff5 in sd::DrawViewShell::FuPermanent(SfxRequest&) (this=0x557f105b9b40, rReq=...) at sd/source/ui/view/drviewse.cxx:548 With this patch, I don't reproduce the pb: diff --git a/svl/source/items/itemset.cxx b/svl/source/items/itemset.cxx index 655956f2d1cc..7ea59f569590 100644 --- a/svl/source/items/itemset.cxx +++ b/svl/source/items/itemset.cxx @@ -1092,9 +1092,7 @@ static void MergeItem_Impl( SfxItemPool *_pPool, sal_uInt16 &rCount, // 2nd Item is set if ( **ppFnd1 != *pFnd2 ) { - // Decision table: set, set, !=, doesn't matter - _pPool->Remove( **ppFnd1 ); - *ppFnd1 = INVALID_POOL_ITEM; + *ppFnd1 = &_pPool->Put( *pFnd2 ); } } } but there are several elements which are impacted, not only 1236 (SDRATTR_TABLE_BORDER) Any thoughts here?
Dear Sven Jäger, 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