Bug 46433 - EDITING: Drag and Drop contents into field in database Form not persistent
Summary: EDITING: Drag and Drop contents into field in database Form not persistent
Status: RESOLVED DUPLICATE of bug 71954
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.4.5 release
Hardware: x86 (IA32) All
: high normal
Assignee: Not Assigned
URL:
Whiteboard: infoprovider:sasha
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-22 01:24 UTC by Dave Legge
Modified: 2013-11-24 19:09 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Simple 1 table database (10.73 KB, application/vnd.oasis.opendocument.database)
2012-02-22 01:24 UTC, Dave Legge
Details
Four lines of text - something to drag & drop (9.63 KB, application/vnd.oasis.opendocument.text)
2012-02-22 01:26 UTC, Dave Legge
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Legge 2012-02-22 01:24:41 UTC
Created attachment 57438 [details]
Simple 1 table database

Drag and Drop data from Writer into field in  database Form does not commit data even when "save Record" icon is clicked on the navigation bar.
Cut & paste seems to work!
Comment 1 Dave Legge 2012-02-22 01:26:11 UTC
Created attachment 57439 [details]
Four lines of text - something to drag & drop
Comment 2 sasha.libreoffice 2012-05-23 03:53:13 UTC
Thanks for bugreport
not reproducible in 3.5.3 on Fedora 64 bit KDE
(but because bugs in Fedora, it works only if window not maximized)
Comment 3 Rainer Bielefeld Retired 2012-05-29 22:25:10 UTC
NOT reproducible with "LibreOffice 3.5.4.2 (RC2) German UI/Locale [Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18] on German WIN7 Home Premium (64bit).

My stes:
0. open both sample documents, arrange windows size and position so that you
   have both documents on screen side by side
1. in text.odb double click "Table1" (Forms)
   > Forms view opens with record ID 0
2. Select word "contrary" in first line in text document
3. <control+x> for cut
4. Click into database "F1" behind text
   > Caret flashes behind old contents
5. <control+v> for paste
   Text "contrary" from text document appears behind "qwerty"

7. Select word "garden" in second row of text document with double click
8. click into selected word, drag and drop behind text in database form
   F2
   > Text "garden" from text document appears behind "uiop"
9. 10 click into F3 behind text
   > Caret flashes behind "asdfghjkl"
10. Click disk symbol in Formular Navigation Toolbar
    Expected: no visible changes, but new contents will be stored and 
              after record forward - record backward fields are shown with
              new contents
   Actual: "garden" disappears permanently as soon as disk symbol clicked


Test result is a little different when I do the test with empty fields in record 3, here contents in F3 remains in Step 10 when I click disc icon, but will not be stored, after record backward - record forward "garden" is lost

Problem also appears when I drag and drop here from a comment input field, underpins suspect that problem is in Database, not in Writer.
Even when I drag and drop contents from one database field to an other I see the problem.              

@sasha
"not reproducible" is a too rare comment. Laptop battery empty, you were not able to test anything? ;-)
What exactly did you test and what exactly were your results? Only with that information we can find out whether different results are related to different proceedings or different OS distributions.

@Lionel:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf.
Comment 4 sasha.libreoffice 2012-05-30 02:02:17 UTC
@ Rainer
I placed my comment here in hope that someone will help in reproducing this bug. Thanks for help in reproducing.
Comment 5 Robert Großkopf 2013-11-24 19:09:49 UTC
This bug has been reported before Bug71954, but in Bug 71954 the behavior has been confirmed. It is described a little bit shorter as done here with 4 comments. So I set this bug as duplicate of Bug71954.

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