Description:
When one localc process does a paste to another, the wrong target area
is sometimes used.

This simulates what would happen if pasting from a non-localc spreadsheet
to localc.


Steps to Reproduce:
1. Start two localc processes.  That likely involves running on a different
   machine not sharing home directory or setting HOME=/tmp/me

   NOTE: if the second process exits immediately, only one process is running.

2. Enter 11,21,12,22 into C7:C8.  (I.e., a 2x2 area.)

3. Select B6:D9 (I.e., a 3x3 area.)

4. Copy

5. Switch to other localc

6. Select A5.

7. Paste

Actual Results:  
A 2x2 data area is pasted into A5:B6.  Ie., the data gets shifted up one
row and one column to the left.  With expressions in the source area it
is possible to get them corrupted.

Expected Results:
A 3x3 data area is pasted into A5:C7


Reproducible: Always


User Profile Reset: No



Additional Info:
This does not happen when doing the cut-and-paste all in one process.

The mini-ods file created and sent via the clipboard simply does not seem
to have any information about the source area.  It would appear that the
bounding box of the non-empty cells is being used as a proxy.

It is possible that the correct area could be deduces from settings.xml

-      <config:config-item config:name="VisibleAreaTop" config:type="int">2709</config:config-item>
-      <config:config-item config:name="VisibleAreaLeft" config:type="int">4515</config:config-item>
-      <config:config-item config:name="VisibleAreaWidth" config:type="int">4516</config:config-item>
-      <config:config-item config:name="VisibleAreaHeight" config:type="int">903</config:config-item>



User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0