Bug 71954 - EDITING: drag and drop text into database form fields will not get stored
Summary: EDITING: drag and drop text into database form fields will not get stored
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 46433 (view as bug list)
Depends on:
Blocks: Database-Forms Drag-and-Drop
  Show dependency treegraph
 
Reported: 2013-11-24 05:26 UTC by e325001
Modified: 2023-08-12 03:05 UTC (History)
4 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 e325001 2013-11-24 05:26:58 UTC
Problem description: 

Steps to reproduce:
1. create a base database caontaining some fields of type text.
   make a form for this database.
2. open some text in a programm.
3. from it drag a few words into several form fields in libreoffice base. 
4. try to save the dataset or switch to next dataset. 
   this should normally save the data into the database.
5. switch back to previously created dataset and check stored entries.
   the input has not been stored.
 (though editing the droped text in the form field bofore saving overcomes this bug)

Current behavior: drag and drop data into form fields is not recognised corectly.

Expected behavior: droped data into form field should be recognised flawlesly.

              
Operating System: Windows 7
Version: 4.1.3.2 release
Comment 1 Robert Großkopf 2013-11-24 09:52:09 UTC
I can confirm this buggy behavior. When I look at the "Save"-button of the navigationbar of the form it seems to recognize the changed text (the button appears colored, isn't greyed out any more). But it doesn't save anything of the field when you press the button "Save Record". You have to set the cursor in the field manually to save the content of the field.

Have tried it with different versions, LO 4.2.0.0 beta1, LO 4.1.3.2, LO 3.3.4 and also LO 3.3.0 beta1. Drag and drop has never worked into the fields of a form, when you didn't set the cursor inside the fields after dropping the content in this fields.

I set this bug to "New" and the version to the first "Inherited From OOo". Set the platform to all, because I have tested with OpenSUSE 12.3 64bit rpm Linux.
Comment 2 Robert Großkopf 2013-11-24 19:09:49 UTC
*** Bug 46433 has been marked as a duplicate of this bug. ***
Comment 3 Alex Thurgood 2015-01-03 17:40:30 UTC Comment hidden (no-value)
Comment 4 QA Administrators 2016-02-21 08:35:44 UTC Comment hidden (obsolete)
Comment 5 Robert Großkopf 2016-02-21 09:21:03 UTC
Bug still exists with LO 5.1.1.1, OpenSUSE 42.1 Leap, 64bit rpm Linux.
Comment 6 Dave Legge 2016-02-24 13:57:31 UTC
Bug Still exists in 
Version: 5.1.0.3
Build ID: 1:5.1.0~rc3-0ubuntu1~trusty0

When I drag and drop into a new record 
and click the Save Record button on the forms navigation bar, 
it issues a "Function Sequence Error"
It does not issue any error if I click the Next or Previous record buttons.

When I drag into an existing record or a new record
and use the Next / Previous navigation buttons to move to an existing record,
then the dropped text remains visible in the text box if there is no text in that field in the record moved to. 
It does clear though when moving to the New Record using the next button.

Dragging from one text box to another on the same record successfully deletes the selected text dragged from the source field, but does not insert it in the target field.

It get weirder - *sometimes* drag and drop from Libreoffice help DOES work!!!
Then it can sometoimes also work from Gedit of Firefox!
Comment 7 Dave Legge 2016-03-02 23:03:07 UTC
And it is still there in Version: 5.1.1.2
Build ID: 1:5.1.1~rc2-0ubuntu1~trusty0
Comment 8 QA Administrators 2017-03-06 15:21:15 UTC Comment hidden (obsolete)
Comment 9 Dave Legge 2017-03-07 17:29:02 UTC
Thanks for the reminder to test.

It gets curiouser.
Drag and drop into a field works IF the field is in focus.
You can drag and drop, 
click the nav bar to the next (new or not) record and repeat.
The dropped text is persistent, and enters the database.

However, if the focus is not given to the target field beforehand, 
the text does not persist.

So, in view of my comment #6 is suspect this bug has not changed.

I am running Version: 5.3.0.3 Build ID: 1:5.3.0~rc3-0ubuntu1~xenial1.1
on Linux Mint Cinnamon 64 bit v3.0.7.
Comment 10 QA Administrators 2018-03-08 03:43:54 UTC Comment hidden (obsolete)
Comment 11 Stefan vW 2018-04-16 13:49:44 UTC
Bug still exists in Version: 6.0.3.2
Build-ID: 8f48d515416608e3a835360314dac7e47fd0b821
CPU-Threads: 2; BS: Mac OS X 10.9.5; UI-Render: Standard; 
Gebietsschema: de-DE (de.UTF-8); Calc: group
Comment 12 QA Administrators 2019-04-17 02:58:32 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2021-08-11 03:58:43 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2023-08-12 03:05:53 UTC
Dear e325001,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

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

Warm Regards,
QA Team

MassPing-UntouchedBug