Created attachment 133365 [details]
spreadsheet for report 107901

Hi Kevin,

I don't reproducce with
LO 5.4.0.0.alpha1+ Build ID: 68a1cb23ede1d4ae6195850190fca6953c30417f
CPU threads: 2; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-05-14_07:04:56
Locale: fr-FR (fr_FR); Calc: CL

With LO 5.3.3.2, I reproduce only the first time I load the file.
Moreover, starting from scratch, I don't reproduce.

Jacques

I tried reproducing and noticed that the steps are a bit imprecise. Apparently step 5 should be: click the rightmost vertical border 3 times so it also affects the horizontal border in the middle. If you click it so only the vertical border is affected, the "Remove border" checkbox will not become active.

I cannot reproduce the bug, however. The border indicators do not reset to the original setting after step 7, no matter where I click on the center vertical line.

It might be useful to record a screencast: https://obsproject.com/

Arch Linux 64-bit, KDE Plasma 5
Version: 5.5.0.0.alpha0+
Build ID: 6b5fc059543c16759abd5eec2576b5b68e96883a
CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on May 21st 2017

(In reply to Buovjaga from comment #5)

I installed the screencast program but couldn't get it to record. 

Simpler Steps:

1. open 107901.ods
2. select the region with contents
3. Format Cells/Borders
(see 107901-1.jpg)
4. click the right most vertical border 3 times
(see 107901-2.jpg)
5. check Remove Border
(see 107901-3.jpg)
6. click the leftmost vertical border once

result - as shown in 107901-4.jpg - the remove border checkbox is unchecked and the rightmost border that you removed has been re-drawn.

Created attachment 133492 [details]
screenshot for second set of steps

Created attachment 133493 [details]
screenshot 2

Created attachment 133494 [details]
screenshot 3

Created attachment 133495 [details]
screenshot 4

confirm, Version: 5.5.0.0.alpha0+
Build ID: 59c9d0653cc42560af48269bb8dee2c2b0b20f68
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-06-06_23:50:05

This bug should be clarified with better sample where just borders are seen and with images in ods file where results/border look of each step are shown.So that we know what the bug really does.

I'm now on Win10 with Calc v. 6.4.4.2

I don't understand why you say "insufficient data". I've given you a spreadsheet with rock-solid 100% reproducible steps. I will try them again now.

Here are the original steps with comments bracketed by ***'s. Note especially the final paragraph, bracketed by ***'s. 

Steps to Reproduce:
1. open the attached spreadsheet
2. select all the cells that have contents (rows 2-10 in columns B and C)
3. right-click and choose Format Cells (note: unlike earlier versions, if this is the first time you've opened this dialog since launching the app, it will take between 30 and 60 seconds to load)

***it only took 15 seconds, but still didn't give any visual indication that it was working (like an hourglass icon)-even the 2nd time it took about 10 seconds to open the format cells dialog***

4. go to the borders tab
5. click on the right-most vertical border 3 times, until no border is shown 
6. the "remove border" checkbox is now active - check it
7. now move on to the center vertical border and click that one three times, until no border is shown (the border setting selected in step 5 now auto-reverts to its previous setting)

Actual Results:  
the border setting selected in step 5 now auto-reverts to its previous setting

Expected Results:
The user should be able to make changes to the border settings in any order without being forced by Calc to only work in a specific (and unexplained) order. This is a cousin to the earlier report where Calc changes the font properties of characters that have not been selected by the user.

***This still behaves exactly as described. I haven't worked on this bug for over a year and I had no problem following my steps. What further clarification are you looking for? The reason I got so frustrated with the Calc beta-testing process is that the powers that be don't seem to understand the concept of "first, do no harm". The idea is to fix what's wrong with Excel (there's so much) without adding new problems.***

see comment for version, system and reproducibility (100%) as of 8/8/2020

Now that I'm thinking about this again, I'm remembering the core problem: unlike Excel, you are differentiating between the right border of cell A1 and the left border of cell B1, but your interface (like Excel) shows only one border (as it should), and you've added the confusing "remove border" checkboxes. You took one of the few good parts of Excel and made it needlessly more complicated - adding confusion and many bugs, but no additional functionality as far as I can see. 


I was extremely frustrated with Excel and when I heard about Libre, I was thrilled that (I thought) others were as frustrated as I was and had set out to create a friendly, smart spreadsheet program. I worked very hard on testing this for a long time, then threw up my hands in frustration that nothing was getting fixed and the core philosophy of making a better Excel seemed to have been a silly fantasy on my part. Still, after more than a year and many new versions, I expected that when I came back to it, at least some of the problems I spent so much effort reporting would have been addressed. This problem is precisely as it was when I left it. If you look through my reports, you'll find a wonderful, elaborate spreadsheet showing all of the harmonies to all the Beatles songs. If someone on your team who's interested in that will take a look at it and try to add more musical data and make it look good, you'll see why I'm so frustrated, why I took the time to report all those bugs and why the design of Calc is fundamentally flawed from a visual point of view. Spreadsheets are not just for math - they're also for making visual presentations that require more power than Word/Writer tables. You've improved on many aspects of Excel, but at the same time you're created new problems not in Excel. I thought the strategy would have been to start with a cleaner, more elegant, smaller-footprint version of Excel without the bugs and then add the graphic and work-flow functionality that Excel users have been crying out for all these years.

Bug was closed because of no reaction to Comment 13.
One should always prepare sample that's clear to tester (who has maybe dozens of other tests to make). 
"Reopened" is when fix was wrong, this is "New" again if you say it's still wrong. 
Please test with master from https://dev-builds.libreoffice.org/daily/master/current.html

Now with the alpha 7 version, and addressing comment 13's request

4. go to the borders tab

see 2020-screenshot-1

5. click on the right-most vertical border 3 times, until no border is shown 

see 2020-screenshot-2

6. the "remove border" checkbox is now active - check it

see 2020-screenshot-3

7. now move on to the center vertical border and click that one three times, until no border is shown (the border setting selected in step 5 now auto-reverts to its previous setting)

see 2020-screenshot-4

Actual Results:  
the border setting selected in step 5 now auto-reverts to its previous setting

Expected Results:
The user should be able to make changes to the border settings in any order without being forced by Calc to only work in a specific (and unexplained) order. This is a cousin to the earlier report where Calc changes the font properties of characters that have not been selected by the user.

Created attachment 164042 [details]
for comment 20

Created attachment 164043 [details]
for comment 20-screenshot 2

Created attachment 164044 [details]
for comment 20-screenshot 3

Created attachment 164045 [details]
for comment 20-screenshot 4

Addressing another part of comment 13 where you say "so we know what the bug really does": the bug is that the Format Cells dialog is broken such that the *user* doesn't know what it does! It doesn't behave logically and has seemingly redundant features. It keeps doing things automatically with no explanation that undo what they user has done. Try it in Excel and you'll see. It doesn't need to be complicated - it can be "what you see is what you get", with one border between two cells and no "remove border" checkbox.

Between two adjacent cells, there is either a line, or no line. It's binary. The Format Cells should allow the user to specify whether there's a line, and if so, what type of line (thickness, color, etc.). The dialog should show this and when the dialog is dismissed the spreadsheet should appear as it appeared in the dialog. Once the user changes the existence of, or appearance of, a line between two cells in the dialog box, it should STAY that way until and unless the user changes it, and it should stay that way in the spreadsheet as well. Libre Calc keeps changing things it hasn't been asked to change.

This same core problem of losing settings runs through the whole interface, whether it's borders, fonts, colors, font styles. Nearly all of the bugs I reported relate to this core design flaw.

I don't see what you are trying to achieve. In the example I don't see borders. 
It's not obvious with thos sample and separate screenshots, better to put all in a single file, with explanation. 

Another problem is with steps. When you select "remove border" you should click OK for that to be applied.

Created attachment 164058 [details]
Excel Format Cells screenshot

(In reply to Timur from comment #26)

>I don't see what you're trying to achieve

It doesn't matter. The bug is in the dialog box itself:

1. when the user makes a change in the dialog box, making another change should not revert the first change (unless there's some logic reason, which there isn't)

2. having to click okay to apply the checkbox setting when there are literally dozens of settings that the dialog box allows the user to assign is counterintuitive in the extreme.

Look at the Excel screenshot. It's simple; it's obvious; it works. There's no need for the totally confusing and buggy "remove border" and no need for the code that changes the user's actions without explanation.

Millions of people use Excel in spite of its horrible flaws. Start with what they know and make it better. With your misguided approached to formatting cells, you've created a whole new house of horrors with different bugs. In all the reports I've submitted, not one person has addressed this. I've given you hours of free beta-testing (I used to do it full time for good money in Silicon Valley). I'm entitled to an explanation instead of all this passive-aggressive nit-picking. Your program is fundamentally broken in terms of the visual control of spreadsheets and until you address this, you're going to continue to drive users away.

Dear Kevin,

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