Created attachment 121799 [details]
table similar to the reported one

I've tested this behavior on Libreoffice 5.1.0.1 on Linux and I was not able to reproduce it. Could you please try the attached file or upload yours for testing.

Created attachment 121815 [details]
example document file

How to reproduce:

1. Open the document.
2. Select range A2:C2.
3. Right click on selected range, and "Cell format"  -> "Number"
4. Set it back to "Number" & "Standard"

The bug: none of the cell's attribute set to "Number" & "Standard"

Sorry about this mixup, it won't happen again.

Can confirm behaviour is also present on Win10, LibreOffice version 5.0.4.2 build ID 2b9802c1994aa0b7dc6079e128979269cf95bc78.

1. Selecting A2:C2 via click+drag
2. Right-click on selected cells
3. Format Cells -> Number, General
4. Click OK
5. Cells are not formatted

This is specific to *only* the standard General format *if* the selected range contains different number formats already, setting another number format works, also setting General on a selection of identical formats works. This is similar to other formatting attributes if a selection contains different attributes of the same type. There is no "ambiguous number format" selection in the formatter (equivalent to "no font size" for fonts) hence the General format is preselected in these cases and hitting OK does not change that.

Created attachment 149686 [details]
In the attached screenshot Screenshot from 2019-03-02 22-19-11.png, pressing "OK" should change the formatting of the selected cells, however due to this bug, pressing "OK" has no effect whatsoever on

In the Calc component, the format Cells dialog does not format cells if selected cells have heterogeneous formats and if the user elects to format the selected cells to the default (Number General) format.  The work-around to this bug is to change the selected cells format to a non-default format, and only then is the user able to change the selected cells format to the default format of "Number General."

Here is a video of the bug in action:

https://www.youtube.com/watch?v=CXZQFnwnt-w

In the attached screenshot Screenshot from 2019-03-02 22-19-11.png, pressing "OK" should change the formatting of the selected cells, however due to this bug, pressing "OK" has no effect whatsoever on the selected cells.

I *tried and failed* to change importance from medium to major because formatting cells is of major importance in a spreadsheet.  Fortunately this bug is a fairly common behavior of many application's UI so many users will be able to intuitively figure out the work-around, but users who do not figure out this work-around will have a bad day. 

Previous comments report this bug happening in Windows 10.  In this present comment I can confirm this bug happening in Linux Mint.

*** Bug 123812 has been marked as a duplicate of this bug. ***

(In reply to Eike Rathke from comment #8)
> This is specific to *only* the standard General format *if* the selected
> range contains different number formats already, setting another number
> format works, also setting General on a selection of identical formats
> works. This is similar to other formatting attributes if a selection
> contains different attributes of the same type. There is no "ambiguous
> number format" selection in the formatter (equivalent to "no font size" for
> fonts) hence the General format is preselected in these cases and hitting OK
> does not change that.

So the issue is that in case of multiple formats in the selection, there should be *no* format selected initially in the dialog (="ambiguous number format"), so that the dialog could detect selection change?

Created attachment 149689 [details]
example with different cell format.ods

(In reply to Mike Kaganski from comment #13)

> So the issue is that in case of multiple formats in the selection, there
> should be *no* format selected initially in the dialog (="ambiguous number
> format"), so that the dialog could detect selection change?

i think so. it works for font, font size, background color, etc.

Thanks for looking at this bug, FYI this bug affects all user input elements of the "Numbers" tab of the "Format Cells" dialog (see attached screenshot) with the exception of the "Decimal Places:" element.  That is to say, the following UI elements are affected on the "Numbers" tab:

Category
Format
Language
Leading Zeros:
Negative numbers red
Thousands separator
Format code
--The unlabeled element which displays a sample of what the formatting looks like

For some reason, the "Decimal places:" element is the only element I can see on this tab not affected by this bug.

Other than these elements on the "Numbers" tab, I didn't easily find any other affected elements on any other tabs of the "Format Cells" dialog.

*** Bug 66584 has been marked as a duplicate of this bug. ***

Confirming bug exists on latest master, and here is a very simple test case:

   Set any cell to Currency format.  Then select the row or column containing that cell and set the format to Number:General ... the cell is not changed.  This problem only occurs with Number:General; if changing to something else it works.

STEPS TO REPRODUCE:

1. Create new calc spreadsheet

2. Set cell B2 to 1.23456789

3. Select B2,  Format->Cells ...
   In 'Numbers' tab, set Category=Currency, Format -$1,234; click OK
   (B2 now displays "$1")

4. Select Row 2 or Column B, Format->Cells ...
   In 'Numbers' tab, set Category=Number, Format General, click OK
   (B2 still displays "$1", incorrectly)

RESULTS: B2 still displays as "$1"

EXPECTED RESULTS: Expecting "1.23456788"


Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 703fb7739a5e604d90e147db6f67917b8d141150
CPU threads: 12; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Dear szg,

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