Bug 49419 - TABLE: Setting cell number format of empty cells is ignored - breaks number recognition
Summary: TABLE: Setting cell number format of empty cells is ignored - breaks number r...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.3.3 release
Hardware: Other All
: highest normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: bibisected, regression
: 58956 (view as bug list)
Depends on:
Blocks: Writer-Tables-Number-Recognition
  Show dependency treegraph
 
Reported: 2012-05-03 02:46 UTC by gs
Modified: 2017-12-29 21:19 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
test case for all possible scenarios.. (17.47 KB, application/3dr)
2015-07-07 22:50 UTC, Cor Nouws
Details
result in 5.1 daily (48.63 KB, image/png)
2015-11-17 18:51 UTC, Cor Nouws
Details
test results daily 20151109 (19.58 KB, text/odt)
2015-11-17 19:11 UTC, Cor Nouws
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gs 2012-05-03 02:46:30 UTC
Problem description: Setting number format for empty table cells does nothing.

Steps to reproduce:
1. Create a table in a writer document.
2. Move the cursor into an arbitrary table cell.
3. In the table number format dialog set the number format to any non standard format.
4. Enter a number into the cell.
5. Set the cursor outside the cell to trigger the formatting.

Current behavior: Nothing happens.

Expected behavior: The previously selected number format is applied to the number.

Opening the number format dialog for that cell again shows the format change has not been saved.

Platform (if different from the browser): Linux 32 bit (upstream binaries)
Comment 1 bfoman (inactive) 2012-10-24 11:38:57 UTC
(In reply to comment #0)
> Steps to reproduce:
> 1. Create a table in a writer document.
> 2. Move the cursor into an arbitrary table cell.
> 3. In the table number format dialog set the number format to any non
> standard format.
> 4. Enter a number into the cell.
> 5. Set the cursor outside the cell to trigger the formatting.
> Current behavior: Nothing happens.
> Opening the number format dialog for that cell again shows the format change
> has not been saved.

Confirmed with:
LO 3.6.3.1 
Build ID: f8fce0b
Windows 7 Professional SP1 64 bit
Comment 2 Cor Nouws 2014-03-11 14:13:09 UTC
*** Bug 58956 has been marked as a duplicate of this bug. ***
Comment 3 Björn Michaelsen 2014-10-11 00:12:44 UTC
Removing regression keyword for now as I couldnt find a version named anywhere in this bug or in the dupe claimed to have worked properly.

Feel free to bring the keyword back, if you specify a version where this used to work as expected.
Comment 4 Cor Nouws 2014-10-11 10:18:33 UTC
Hi Bjoern,

At least it works in LibreOffice 3.3.0 - providing of course via Tools > Options > Writer > Table  Number recognition is activated..

Will try to find first version where it is broken.
Comment 5 Cor Nouws 2014-10-11 11:38:19 UTC
Last version where it is OK: 4.0.2.2
First version where it is broken: 4.0.3.1
Comment 6 Matthew Francis 2014-12-04 01:58:07 UTC
I can reproduce the described behaviour at the start of the 43all bibisect repository (3.5.0)

However, by the end it appears to have already been fixed. It also still works as expected in 4.3.4.1 release and 4.5 master.

Setting RESOLVED FIXED
Comment 7 Cor Nouws 2014-12-04 09:18:37 UTC
It's not resolved in 4.3.5.1 on Linux, 32 bits
Comment 8 Cor Nouws 2014-12-04 09:20:52 UTC
new document
insert table
set number format of cell A1 to currency
 > caret is right side of the cell = OK
insert number, e.g. 34,5 (Dutch locale)
 > number jumps to left = WRONG
again set number format of cell A1 to currency
 > number jumps to right and is preceded by  "€ "
Comment 9 Cor Nouws 2014-12-04 09:21:31 UTC
why has this never been marked as MAB ?
Comment 10 Matthew Francis 2014-12-04 10:06:40 UTC
OK, following comment 8 I get the following from bibisect-43all:
 b68886f4c56ebc4cdf94aee9753398ccce28bb41 is the first bad commit
commit b68886f4c56ebc4cdf94aee9753398ccce28bb41
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Wed Nov 27 01:52:45 2013 +0000

    source-hash-90830788b1f8fd61ea86135712868aeda395edd0
    
    commit 90830788b1f8fd61ea86135712868aeda395edd0
    Author:     Noel Grandin <noel@peralex.com>
    AuthorDate: Mon Sep 16 14:31:09 2013 +0200
    Commit:     Noel Grandin <noel@peralex.com>
    CommitDate: Tue Sep 17 09:06:12 2013 +0200
    
        convert the SvxAutoCorrect::FindIn* methods from String to OUString
    
        Change-Id: Ida2f39b75f73137a4164d95d7f1e9a6cd34a322f

git bisect start 'latest' 'oldest'
# good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
# bad: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect bad 4850941efe43ae800be5c76e1102ab80ac2c085d
# skip: [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681
git bisect skip a043626b542eb8314218d7439534dce2fc325304
# skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
# skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
# skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
# bad: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930
git bisect bad c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31
# bad: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930
git bisect bad c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31
# good: [1d4980621741d3050a5fe61b247c157d769988f2] source-hash-89d01a7d8028ddb765e02c116d202a2435894217
git bisect good 1d4980621741d3050a5fe61b247c157d769988f2
# skip: [89110ca258fa7a15dfc546acfb39e76fc3eb2a44] source-hash-e450a2c506ac7cd4433b0f93fc750a89919bc03c
git bisect skip 89110ca258fa7a15dfc546acfb39e76fc3eb2a44
# good: [1cca92a409385d9288c28a54d5e3008e56728bc0] source-hash-7be7824bbbdeee6fa998b950e6046ab37fe690cb
git bisect good 1cca92a409385d9288c28a54d5e3008e56728bc0
# skip: [5fa28ce2931a35ae64ae08d3904cfb76d24459d8] source-hash-2304beaca33c63b94df99cb827716f00ce259f9a
git bisect skip 5fa28ce2931a35ae64ae08d3904cfb76d24459d8
# bad: [2a9ff869c5638dc5c3aa387d0fe55c3291c86288] source-hash-01b7e04172889cbc9e4ac404b105e18ddc062d6f
git bisect bad 2a9ff869c5638dc5c3aa387d0fe55c3291c86288
# bad: [9771d0c212cfa71b07742ff3dc5c05df22d600eb] source-hash-a9a0933ec67eab0ec31c8fadb60fb8e8e3e90485
git bisect bad 9771d0c212cfa71b07742ff3dc5c05df22d600eb
# bad: [b68886f4c56ebc4cdf94aee9753398ccce28bb41] source-hash-90830788b1f8fd61ea86135712868aeda395edd0
git bisect bad b68886f4c56ebc4cdf94aee9753398ccce28bb41
# good: [56d7a7963ef4d32b0c5b60dc5f85d4bc218785d9] source-hash-1a412370ab03af8f3865ccbfaaa8dcff1d0ac0ad
git bisect good 56d7a7963ef4d32b0c5b60dc5f85d4bc218785d9
# good: [1cb483c5f696c8e7d262c7959e482f2bc2edc0cb] source-hash-59373b753902f69cd44d183568b084429322e7ab
git bisect good 1cb483c5f696c8e7d262c7959e482f2bc2edc0cb
# good: [d3b6cc309837997ba693f21d82b5d8ce866db756] source-hash-cb4e009c4539c535108021934e545194b35cad9d
git bisect good d3b6cc309837997ba693f21d82b5d8ce866db756
# first bad commit: [b68886f4c56ebc4cdf94aee9753398ccce28bb41] source-hash-90830788b1f8fd61ea86135712868aeda395edd0
Comment 11 Björn Michaelsen 2014-12-18 10:16:11 UTC
(This is an automated message.)

LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched.

You can find out more about MABs and how the process works by contacting libreoffice qa on irc:

 http://webchat.freenode.net/?channels=libreoffice-qa

The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list):

 https://wiki.documentfoundation.org/QA
Comment 12 Cor Nouws 2015-04-11 13:44:53 UTC
still a problem in daily
 Version: 4.5.0.0.alpha0+
Build ID: 9efd80ac32a80656ed6482df69615227d12bc6d9
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-03-30_16:43:31
Locale: nl_NL
 
I saw an older issue tdf#32082 that is for the same problem, and a commit that should have fixed it:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=f8be3d02573c4d6d753b5e0c1a449e932f94bd81
Comment 13 Matthew Francis 2015-04-17 15:38:44 UTC
@Cor Nouws:
Do you by any chance have both "Number recognition" and "Number format recognition" enabled? I've identified an issue, just not sure if it's exactly the issue you're seeing.

As I understand it, there are three cases which should work with number recognition, covering a table cell with a number format already applied, when:

A) Both "Number recognition" and "Number format recognition" are off
B) Only "Number recognition" is on
C) Both "Number recognition" and "Number format recognition" are on

(in each case, a formatted number should result from entry into the cell, with some variations on what input is acceptable and what the result is. There appear to be other problems with which number results and what kind, but that's not the issue here)

Before the above-mentioned commit f8be3d02573c4d6d753b5e0c1a449e932f94bd81, it seems to me that, for at least UK and Dutch currency formats, when inputting numbers of the forms "12.34" and "12,34" respectively,

A) FAILS, B) Works, C) Works

whereas after,

A) Works, B) Works, C) FAILS
Comment 14 Cor Nouws 2015-04-19 19:31:11 UTC
(In reply to Matthew Francis from comment #13)
> @Cor Nouws:


Thanks for your hints Matthew. I marked this issue for consistent scenario testing..
Comment 15 Cor Nouws 2015-07-07 22:50:30 UTC
Created attachment 117111 [details]
test case for all possible scenarios..

Attached a test case...
Some work to fiddle all out, and not surprisingly some things break now and then!
Comment 16 Cor Nouws 2015-07-07 22:52:54 UTC
NB
In 5.0.0.2,
 -  setting number recognition and format date in an empty cell, does work. Nice.
 -  setting number recognition and format number in an empty cell, does not work..

Shouldn't we ask on a list to find some brave testers for this?
Comment 17 Niklas Johansson 2015-11-06 16:27:44 UTC
Hi, I pushed a patch that touches this issue and hopefully fixing a few remaining issues. I've been testing this back and forth so much I'm unsure of what works and what doesn't. Could someone please help me test this.
Comment 18 Buovjaga 2015-11-06 20:34:02 UTC
(In reply to Cor Nouws from comment #16)
>  -  setting number recognition and format number in an empty cell, does not
> work..

This now seems to work in 5.1.
If I enable Tools > Options > Writer > Table  Number recognition and format a cell as Number, some non-standard, user-defined thing, it stays left-aligned (as in Expected).

I hope I understood it correctly.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: db6a928a420868b2a80ba11c8d46151d16c13624
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-05_22:13:24
Locale: fi-FI (fi_FI)
Comment 19 Cor Nouws 2015-11-17 18:48:17 UTC
(In reply to Beluga from comment #18)

> This now seems to work in 5.1.
> If I enable Tools > Options > Writer > Table  Number recognition and format
> a cell as Number, some non-standard, user-defined thing, it stays
> left-aligned (as in Expected).
> 
> I hope I understood it correctly.

If you first did set the number recognition and then entered values in the cells: yes :)
Comment 20 Cor Nouws 2015-11-17 18:51:40 UTC
Created attachment 120603 [details]
result in 5.1 daily

this definitely works in 5.1 daily 2015-11-09
Comment 21 Cor Nouws 2015-11-17 18:58:41 UTC
Hi Niklas,

(In reply to Niklas Johansson from comment #17)
> Hi, I pushed a patch that touches this issue and hopefully fixing a few
> remaining issues. I've been testing this back and forth so much I'm unsure
> of what works and what doesn't. Could someone please help me test this.

Thanks a lot!
I think your commit   http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa334d55ee34c125f6f4fdfaadbc1ed8fa33f5bc
did a great job :)

Would it be possible to push that to the 5.0 branch too?
Still some releases to go there.
Comment 22 Cor Nouws 2015-11-17 19:11:32 UTC
Created attachment 120604 [details]
test results daily 20151109

@matthew

(In reply to Matthew Francis from comment #13)

> A) Both "Number recognition" and "Number format recognition" are off
> B) Only "Number recognition" is on
> C) Both "Number recognition" and "Number format recognition" are on
> 
> Before the above-mentioned commit f8be3d02573c4d6d753b5e0c1a449e932f94bd81,
> it seems to me that, for at least UK and Dutch currency formats, when
> inputting numbers of the forms "12.34" and "12,34" respectively,
> 
> A) FAILS, B) Works, C) Works
> 
> whereas after,
> 
> A) Works, B) Works, C) FAILS

I think all works fine - see table in attached.
Of course there are more corer cases that are not covered in that table, but I did additional test and confirm that if i.e. format is set, but not recognition, 12-1 will not result in a date in a cell with decimal number format, but will in a cell with date formatting.
Comment 23 Buovjaga 2015-11-18 06:30:32 UTC
Let's set to fixed for now.
Comment 24 Niklas Johansson 2015-11-20 12:57:00 UTC
(In reply to Cor Nouws from comment #21)
> Would it be possible to push that to the 5.0 branch too?
> Still some releases to go there.

Sure, that was always my intent. I just wanted a few more eyes checking that everything seems ok. I cherry-picked the change and pushed it to gerrit for review.
https://gerrit.libreoffice.org/20082
Comment 25 Robinson Tryon (qubit) 2015-12-17 06:52:20 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]
Comment 26 Cor Nouws 2017-12-29 21:19:22 UTC
testing for tdf 48763 I verify this one ;) 
Version: 6.1.0.0.alpha0+
Build ID: a9b202a6b7000e7af34f2a639ca207122a3968bf
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-12-26_23:09:36
Locale: nl-NL (nl_NL.UTF-8); Calc: group threaded