Bug 72205 - LibreOffice Database - LONGVARCHAR anomaly when trying to dismiss a window without first saving
Summary: LibreOffice Database - LONGVARCHAR anomaly when trying to dismiss a window wi...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.1.3.2 release
Hardware: x86-64 (AMD64) All
: medium minor
Assignee: Lionel Elie Mamane
URL:
Whiteboard: target:5.1.0 target:5.0.3
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-01 18:39 UTC by Alan Wheeler
Modified: 2016-10-25 19:21 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Procedure to reproduce the unwanted situation (22.50 KB, application/msword)
2013-12-01 18:39 UTC, Alan Wheeler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Wheeler 2013-12-01 18:39:44 UTC
Created attachment 90060 [details]
Procedure to reproduce the unwanted situation

Unexpected repeat displaying of warning message “The content of the current form has been modified. Do you want to save your changes?”

See the attachment (a Microsoft Word 2000 .doc file) for a very detailed description of how to reproduce the situation.
Comment 1 Alan Wheeler 2013-12-01 18:43:12 UTC
Comment on attachment 90060 [details]
Procedure to reproduce the unwanted situation

Open LibreOffice. From the menu bar, select “File”, “New”, “Database”.

When the Database Wizard panel appears at Step 1, accept the default of “Create a new database” - just select “Next>>”.

At step 2, select “No, do not register the database” , check “Open the database for editing” and “Create tables using the table wizard”, then select “Finish”.

When the “Save As” panel appears, accept the default name of “New Database.odb” and storage location (probably “My Documents”) - just select “Save”.

When the Table Wizard panel appears at Step 1, accept the default Category of “Business” and Sample table of “Assets” - just select “Comments” then “>” to move “Comments” from “Available fields” to “Selected fields”, then select “Next>”.

At step 2, accept the default Field name of “Comments”, the Field type of “Memo [LONGVARCHAR]” and Entry required of “No” - just select “Next>”.

At step 3, leave “Create a primary key” checked and “Automatically add a primary key” selected. Check “Auto value”, then select “Next>”.

At step 4, accept the default table name of “Assets”, select “Create a form based on this table” then select “Finish”.

When the Form Wizard appears at step 1, select “>>” to move “ID” and “Comments” from “Available fields” to “Fields in the form”, then select “Next>”.

At step 2, no Subform is required, so just select “Next>”.

At step 5, select the second arrangement of controls (“Columnar - labels on top”), then select “Finish”.

Select “Forms”, then “Assets”.

Type anything in the “Comments” field, then without moving the cursor out of the “Comments” field, try to dismiss the form window. A warning “The content of the current form has been modified. Do you want to save your changes?” will be displayed - this is as I would expect. If you reply “No”, the window is dismissed and subsequent redisplaying of the form show that the data input has been correctly discarded - again, this is as I would expect. However, if you reply “Yes”, the window is not dismissed - instead the warning is re-displayed - this seems wrong to me. Whether you subsequently reply “Yes” or “No”, the window is dismissed and subsequent redisplaying of the form shows that the data input has been correctly saved, implying that the second warning was unnecessary.

After further modification of the “Comments” field, it is similarly normally necessary to reply twice to the warning if you try to dismiss the form window without first saving changes. However, there is one exception to this - if all text in the “Comments” field is deleted, it is only necessary to reply “Yes” once to the warning before the form window is dismissed.

If the contents of the “Comments” field are modified then cursor is moved out of the “Comments” field before trying to dismiss the form window, behaviour is as I would expect - ie. the warning is only displayed once.

If, when defining the table, the “Comments” field is defined as Text [VARCHAR], rather than as Memo [LONGVARCHAR], behaviour is also as I would expect.

I don’t think this is a duplicate of bug 65644, but may be related..
Comment 2 Alan Wheeler 2013-12-03 12:38:00 UTC
Ignore the attachment - looks like a Microsoft Word file attachment doesn't display as I expected - instead, I've copied its contents as plain text as a comment.
Comment 3 Terrence Enger 2013-12-04 02:45:10 UTC
I see this in my debug build of master commit 3d7d662, fetched 2013-11-19, built and executing on debian-wheezy.  Setting platform = All.
Comment 4 Alex Thurgood 2015-01-03 17:41:17 UTC
Adding self to CC if not already on
Comment 5 Alan Wheeler 2015-02-16 00:26:10 UTC
Still present in LibreOffice 4.4.1.1
Comment 6 Alan Wheeler 2015-03-30 23:14:52 UTC
Still present in LibreOffice 4.4.2.2
Comment 7 Alan Wheeler 2015-05-08 09:41:56 UTC
Still present in LibreOffice 4.4.3.
Comment 8 Alan Wheeler 2015-10-11 16:43:54 UTC
Still present in LibreOffice 5.0.2.2
Comment 9 Julien Nabet 2015-10-17 17:11:04 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

Lionel: thought you might be interested in this one. Just a guess but since it indeed works with TEXT (compared to LONGVARCHAR) I wonder if a similar fix to http://cgit.freedesktop.org/libreoffice/core/commit/?id=e6c329cc55af00fec99ada5cac15b2d4752b7474 could help. Again, just a guess:-)
Comment 10 Julien Nabet 2015-10-17 17:24:15 UTC
(In reply to Julien Nabet from comment #9)
> On pc Debian x86-64 with master sources updated today, I could reproduce
> this.
> 
> Lionel: thought you might be interested in this one. Just a guess but since
> it indeed works with TEXT (compared to LONGVARCHAR) I wonder if a similar
> fix to
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=e6c329cc55af00fec99ada5cac15b2d4752b7474 could help. Again, just a
> guess:-)

Sorry, after having added debug traces locally, it's completely unrelated :-(
Comment 11 Commit Notification 2015-10-18 16:48:10 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b969f364ee773e3d202607f6bcddba2ac85c19c8

tdf#72205 a VARCHAR and a LONGVARCHAR should compare equal

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2015-10-18 16:48:18 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=36303eee68680dd1f7a080b93caf8fca65672799

tdf#72205 when saving changes, mark we did a prepareClose

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Julien Nabet 2015-10-19 21:29:09 UTC
I've updated my local repo so now  includes the patch and indeed I don't reproduce the problem.
Thank you Lionel!
Comment 14 Commit Notification 2015-10-20 13:06:22 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-5-0-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c610be2d7c63a67e860ed82064e32a8126ff42d1&h=libreoffice-5-0-3

tdf#72205 a VARCHAR and a LONGVARCHAR should compare equal

It will be available in 5.0.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Commit Notification 2015-10-20 13:07:53 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0fff374fc0e9d3ea76d0aa0a0466467078f0519d&h=libreoffice-5-0

tdf#72205 a VARCHAR and a LONGVARCHAR should compare equal

It will be available in 5.0.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Julien Nabet 2015-10-20 13:09:54 UTC
Let's simplify a bit.
Comment 17 Alan Wheeler 2015-10-24 22:30:28 UTC
Tested by downloading and running Version: 5.0.4.0.0+
Build ID: a3b56a4f3eb55fad4bf10589a0acbc7879429cdd
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-0, Time: 2015-10-24_10:57:17

I am happy to verify that the problem has been fixed - thanks Lionel.
Comment 18 Commit Notification 2015-10-27 05:59:25 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-5-0-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a1c960d9c001943d79fda64d664174dc7fda61ac&h=libreoffice-5-0-3

tdf#72205 when saving changes, mark we did a prepareClose

It will be available in 5.0.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Commit Notification 2015-10-27 06:09:49 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b392270d68d483a1566e7281c6400874a42ce4b3&h=libreoffice-5-0

tdf#72205 when saving changes, mark we did a prepareClose

It will be available in 5.0.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.