Bug Hunting Session
Bug 66483 - EDITING: When pasting a string with double quotes with Paste Special > Unformatted text, the quotes are pasted too (Regression or intended or good change?)
Summary: EDITING: When pasting a string with double quotes with Paste Special > Unform...
Status: CLOSED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.0.1 rc
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL: https://issues.apache.org/ooo/show_bu...
Whiteboard: BSA
Keywords: regression
Depends on:
Blocks:
 
Reported: 2013-07-02 06:38 UTC by dany franck
Modified: 2013-07-04 14:49 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dany franck 2013-07-02 06:38:50 UTC
Problem description: 
When pasting a string with double quotes, the quotes where ignored in previous versions. In 4.1.0.1rc they are not.

Steps to reproduce:
1. copy "essai" 
2. paste in calc

Current behavior:
the cell contains "essai"

Expected behavior:
the celle should be essai

              
Operating System: Windows 7
Version: 4.1.0.1 rc
Last worked in: 4.0.4.2 release
Comment 1 Cor Nouws 2013-07-02 07:51:31 UTC
Hi Danny,
Thanks for the report.
I see the behaviour in 4.1.0rc1, but in 4.0.4 and 3.6.6 the behaviour is the same. In any case on Ubuntu....
So ??
Regards,
Cor
Comment 2 dany franck 2013-07-02 14:30:11 UTC
The same with Mageia. But I'm using W7 at office and before 4.1 all was same as with Excel (quotes ignored), that's why I named it a regression.
Comment 3 Ken Biondi 2013-07-03 01:55:01 UTC
I was unable to recreate this bug.  I tested in LO 4.0.4.2 , LO 4.1.0.1 and Excel 2010.  Each time I copied "essai" and then pasted "essai".  "essai"  appeared in the cell after each paste. 

Used:

WIN 8 x86_64
Comment 4 Mike Kaganski 2013-07-03 02:22:10 UTC
If you simply paste the copied text, it will indeed contain the double quotes. That is because copying from browser copies with formatting, and paste by default chooses formatted text.

But if you choose Paste Special -> Plain Text, it will be pasted without quotes. (I tested with 3.6.3.2)
Comment 5 dany franck 2013-07-03 09:07:49 UTC
I am using Office2003 and the copy was made within scite or any other editor.
In previous versions (and we are using LO/OO for a long time) the paste in calc ignores the double quotes " as does Office2003.
No Office2010 for verifying.
Comment 6 retired 2013-07-03 09:19:51 UTC
I can confirm the described behavior.

In Excel 2010 when copying "essai" from a plain-text document and pasting that text in a spreadsheed only essai appears. That behavior does indeed not occur when copying the text from a browser.

When doing the same using LO 4.1.0.1 "essai" appears in the cell despite being copied from a plaintext document.

Setting to NEW.
OS to ALL.

But I'm not sure if this is really a bug? Maybe it's rather a bug with MS Office? In my opinion if you copy paste something and the content you copied does arrive as copied that's not really a bug is it?

Can a dev elaborate on this? Maybe NOTABUG?
Comment 7 dany franck 2013-07-03 11:43:12 UTC
The double quotes are used to identify the content as a string. It is difficult to import data automatically without such a pseudo-formatting.
Comment 8 Cor Nouws 2013-07-03 13:14:16 UTC
(In reply to comment #4)

> But if you choose Paste Special -> Plain Text, it will be pasted without
> quotes. (I tested with 3.6.3.2)

Where in the summary/title of this bug, or in the initial description, is stated that paste as plain text is involved?
Comment 9 Cor Nouws 2013-07-03 13:15:21 UTC
(In reply to comment #6)

> I can confirm the described behavior.

You do not ...

> In Excel 2010 when copying "essai" from a plain-text document and pasting
> that text in a spreadsheed only essai appears. That behavior does indeed not
> occur when copying the text from a browser.

Because we test LibreOffice here, not excel :)
Comment 10 Cor Nouws 2013-07-03 13:18:02 UTC
As it is now, will close this as WorksForMe.
Just waiting for some decent information...
Comment 11 Mike Kaganski 2013-07-03 13:54:05 UTC
Cor,

(In reply to comment #8)
> Where in the summary/title of this bug, or in the initial description, is
> stated that paste as plain text is involved?

The OP seems to have forgotten to mention this; or doesn't know these technical details. This led to inability of triagers to reproduce the stated behavior. I gave missed information; confirmed behavior in older LO versions. The triage work consists partly in helping users to describe problems clearer, or sometimes do it for them; what do you find wrong here?

(In reply to comment #9)
Then Wilhelm confirms the current state in LO 4.1 (taking the new information into account), and its divergence with MS Excel (this was mentioned by OP in Comment 2). What could be so bad here, that you chose to ignore the third paragraph of Comment 6 and state that Wilhelm talked about Excel only?

The abovementioned data confirms the OP observation; the only piece left is decision on is it a problem or intended change, and thus should it be fixed or not. Probably you need some more information, then please ask for it.

I'm afraid you had a bad day. :) Take it easy!
Comment 12 Cor Nouws 2013-07-03 17:37:09 UTC
Hi Mike,

(In reply to comment #11)

> I'm afraid you had a bad day. :) Take it easy!

Hmm, that goes without a saying :)
To be more precise: I'm a bit too tired currently to try to do the right interpretation of comments. Triaging of comments on reports that need to be triaged ... :)

So pls, when someone finds that a summary is not precise, incomplete: update it.
Handy for all that search issues, start working on a specific one etc. usw.

OK, apologies for sounding a bit harsh before.
I can confirm this one :)

(And indeed: is it intended, and improvement, or a regression ??)
Comment 13 Mike Kaganski 2013-07-04 00:56:02 UTC
Could it be Commit 9dba77d1b5bb2d513e8d6b67c83dc6e858e35f66?
Just in case, I CC Eike Rathke (the author of said commit).
Eike, could you please advise on this problem?
Comment 14 Eike Rathke 2013-07-04 10:21:22 UTC
Pasting a single line as unformatted text shall paste all text in the clipboard and not attempt to automatically modify content. Earlier versions did that, which was wrong and even lead to erroneous behavior like pasting
"foo" bar baz
resulted in foo only.
Comment 15 Mike Kaganski 2013-07-04 11:52:37 UTC
Well...

I see it a good option to treat a string containing two and only two double quotes at the very start and at the very end of the text as a special case. This would enable the scenario that OP described - when a string to be pasted that otherwise would be treated as a number, or a date/time, etc. If such a check would exist, the mentioned "foo" bar baz string would be treated as the one that must go as is - containing spaces, and "123" would become string 123, not number.

However, another option for OP could be not to enclose the copied text in quotes, but adding single apostrophe in front of such "numbers".

The decision made by Eike has the advantage that it makes the paste operation consistent, and there will be no surprise when one gets different results copying the same text from plain-text editor or from web page.
Comment 16 dany franck 2013-07-04 12:50:53 UTC
The advantage of the double quote solution for identifying strings is that it was supported by the two office suites used in our enterprise. Sure I can use a single quote with LO, but since >LO 3.3 I had to replace it after pasting because it appears in the cell.
Comment 17 dany franck 2013-07-04 12:57:34 UTC
And the treatment of double quotes is also used when opening csv files.
Comment 18 Eike Rathke 2013-07-04 13:31:23 UTC
(In reply to comment #15)
> I see it a good option to treat a string containing two and only two double
> quotes at the very start and at the very end of the text as a special case.

Not sufficient. Consider
"foo" bar "baz"
that then would result in
foo" bar "baz
Even worse with
"foo" "bar" "baz"
to become
foo" "bar" "baz


> This would enable the scenario that OP described - when a string to be
> pasted that otherwise would be treated as a number, or a date/time, etc. If
> such a check would exist, the mentioned "foo" bar baz string would be
> treated as the one that must go as is - containing spaces, and "123" would
> become string 123, not number.

Remember that this is about clipboard content, so why not just select and copy 123 instead of "123"?


(In reply to comment #17)
> And the treatment of double quotes is also used when opening csv files.

With which you get a dialog where you can tweak things, no hidden automatic processing. This dialog btw is also presented when pasting clipboard content that consists of more than one line.
Comment 19 Mike Kaganski 2013-07-04 14:05:53 UTC
(In reply to comment #18)
> (In reply to comment #15)
> > I see it a good option to treat a string containing two and only two double
> > quotes at the very start and at the very end of the text as a special case.
> 
> Not sufficient. Consider
> "foo" bar "baz"
> that then would result in
> foo" bar "baz
> Even worse with
> "foo" "bar" "baz"
> to become
> foo" "bar" "baz

Sufficient :) You misread my sentence: "Two and only two". It means that if a double quote happens in between, the check fails.
Comment 20 dany franck 2013-07-04 14:49:33 UTC
(In reply to comment #18)
 
> Remember that this is about clipboard content, so why not just select and
> copy 123 instead of "123"?

Calc is used as the frontend for requests on databases. Some fields in the database are strings but exclusively written with numbers (ex. goods identification for french government) like 0124578. When such a field is not typed as string it comes as 124578 in Calc.
I have a lot of this exemples.
 
> 
> 
> (In reply to comment #17)
> > And the treatment of double quotes is also used when opening csv files.
> 
> With which you get a dialog where you can tweak things, no hidden automatic
> processing. This dialog btw is also presented when pasting clipboard content
> that consists of more than one line.

But when accepting the default, the double quotes where ignored. 

I've mentionned this "bug" because it differs from versions before. You can consider that it should be as it is yet, but I think all data imports (paste from an other source or cvs files) should have the same treatment.