Bug 108333 - Undo results in formatting which had never existed in the document - duplicate of existing bug
Summary: Undo results in formatting which had never existed in the document - duplicat...
Status: RESOLVED DUPLICATE of bug 107857
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisectRequest, regression
Depends on:
Blocks: Undo-Redo Cell-Direct-Formatting-Parts
  Show dependency treegraph
Reported: 2017-06-04 08:31 UTC by Kevin
Modified: 2020-03-08 19:17 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:

steps, expected results and actual results for 108333 (10.87 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-06-04 08:32 UTC, Kevin

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin 2017-06-04 08:31:44 UTC
Rather than undo-ing to a previous state, selecting undo applies bizarre font formatting that had never been present in the document since its creation!

Steps to Reproduce:
1. open attached spreadsheet (steps are shown with easy to understand graphic examples)

Actual Results:  
Undo sets a whole cell to Bold that had previously only had certain characters bolded.

Expected Results:
Undo should revert to the previous state.

Reproducible: Always

User Profile Reset: No

Additional Info:
As you'll see, several other (even worse) bugs are also revealed with these steps but I think their root causes are characterized in other reports. I couldn't find the undo problem reported elswhere.

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Comment 1 Kevin 2017-06-04 08:32:37 UTC
Created attachment 133839 [details]
steps, expected results and actual results for 108333
Comment 2 Kevin 2017-06-04 08:39:00 UTC
I think the core problem is that Calc has a nasty habit of changing font attributes without being asked to, and makes these unwanted changes based on the attributes of previous unselected characters. So when you "undo", it only "undoes" what you typed and then when it "retypes" the characters that had been there before its proactive and sadistic auto-formatting kicks in and you wind up with a formatting pattern that had never been present in the cell at any point.
Comment 3 Telesto 2017-06-05 17:19:40 UTC
Conforming with
Build ID: ec79f3453471ee9b6ae32e71ff16ea99d9b7751c
CPU threads: 4; OS: Windows 6.19; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-05-28_23:21:44
Locale: nl-NL (nl_NL); Calc: CL

and with
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
Comment 4 QA Administrators 2018-06-06 02:46:24 UTC Comment hidden (obsolete)
Comment 5 Xavier Van Wijmeersch 2018-06-06 08:50:53 UTC
still reproduce the problem

Build ID: 35c00b2ece11b7f60c5ffba10bd7083d4e7bc4f2
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group threaded
Comment 6 QA Administrators 2019-06-07 02:53:10 UTC Comment hidden (obsolete)
Comment 7 Thomas Lendo 2019-06-09 01:07:00 UTC
Still reproducible with Version:
Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: de-DE (de_DE.UTF-8); UI-Language: en-US
Comment 8 Timur 2020-01-09 17:33:00 UTC
This is a  duplicate of existing bug that reports paste or typing not as replacing selected text, but as delete+insert.
I cannot find it now to mark.
Comment 9 Timur 2020-03-08 19:17:14 UTC

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