Bug 74138 - Paste behavior for text inconsistent EDITING FORMATTING
Summary: Paste behavior for text inconsistent EDITING FORMATTING
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.4.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-28 05:27 UTC by Tom Jones
Modified: 2014-11-11 16:32 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Problem illustrated, with application version (303.23 KB, image/png)
2014-09-03 13:34 UTC, Tom Jones
Details
Problem illustrated, example file from "Version: 4.3.0.4" (36.17 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-09-03 13:36 UTC, Tom Jones
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Jones 2014-01-28 05:27:36 UTC
If I set all cells format as Text and, from Notepad++, copy/paste the data (without quotes) "00:00:13.977" into Calc.  Then the cell shows "00:00:13.977" as expected.

If I follow the same process, but instead source the data from Fiddler, then the cell contents are "00:00:13.98".  This is change in behavior is unexpected.  Regardless of data source for the copy/paste, surely the sole point of the Text call format is be the guarantee that no data will change.

(Use case is performance testing websites, gathering data with LibreOffice and Fiddler)
Comment 1 Cor Nouws 2014-01-28 07:07:54 UTC
Hi Tom,

Did you try Edit > Paste special .. Text only?

Regards,
Cor
Comment 2 Tom Jones 2014-01-29 00:23:58 UTC
Thanks for the prompt reply.

The text only option does not work on a normal cell, but does work if you
first format the cell as Text.  So it's a two step process; format cell as
Text and then paste special Text Only.

I thought I should raise this as a bug because for any program I would expect the same behavior for the same data in the same workflow, regardless of data source.
Comment 3 QA Administrators 2014-08-04 16:18:00 UTC
Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team
Comment 4 QA Administrators 2014-09-03 12:05:38 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided):

a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. 
Please do not:
a) respond via email 
b) update the version field in the bug or any of the other details on the top section of FDO
Comment 5 Cor Nouws 2014-09-03 12:14:06 UTC
Hi Tom,

(In reply to comment #2)

> I thought I should raise this as a bug because for any program I would
> expect the same behavior for the same data in the same workflow, regardless
> of data source.

I expect there is some involvement from data-interpretation/rounding here.
(Sorry for not responding earlier. Some unseen mails in the QA-folder ..)
Cor
Comment 6 Tom Jones 2014-09-03 13:34:01 UTC
Created attachment 105683 [details]
Problem illustrated, with application version
Comment 7 Tom Jones 2014-09-03 13:36:50 UTC
Created attachment 105684 [details]
Problem illustrated, example file from "Version: 4.3.0.4"
Comment 8 Tom Jones 2014-09-03 13:54:46 UTC
My original steps for replication could have been much better, sorry about that.

For my 6 tests 1 of the results are different, which I would consider the bug.  I would have expected all 6 to produce identical results.  I have attached the test sample.

I have attached the image "Problem illustrated, with application version".  The screenshot shows LibreOffice, Notepad++, and Fiddler open.  This should show everything, hopefully.  Steps are;
--I set Column A in LibreOffice as Text.
--I copy from Fiddler (highlighted as "1"), and paste to LibreOffice (highlighted as "2") in 3 different ways, per the notes in Column B.
--I then paste (still using Fiddler 'copy') to Notepad++ (highlighted as "3").
--I copy from Notepad++ (highlighted as "3"), and paste to LibreOffice (highlighted as "4") in the same 3 different ways, per the notes in Column B.

I have also attached this test .ods file as ' Problem illustrated, example file from "Version: 4.3.0.4" '

This test was on Windows 7 SP1, 64 bit.  LibreOffice; Version: 4.3.0.4, Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0
Comment 9 Timur 2014-10-29 11:12:24 UTC
(In reply to Tom Jones from comment #7)
> Created attachment 105684 [details]
> Problem illustrated, example file from "Version: 4.3.0.4"

In this example, 23:10:04.321 is shown as Text cell, and 23:10:04,32 (with comma) is shown as Time cell and rounded (and it seems to be time indeed).
I cannot reproduce this with LO 4.3.2, maybe because in my regional settings, separator is ",". But, if I paste for example 11:58:45,541 then it's recognized as Time and I see 11:58:45,54. 
I guess you have "." as a separator. This behavior seems thus normal. 
I suggest this be closed as "WorksForMe".
Comment 10 Timur 2014-11-11 16:32:35 UTC
rather, notabug