Bug 63695 - EDITING: subform does not properly get focus on button click or listbox touch; leads to ignoring changes in subform
Summary: EDITING: subform does not properly get focus on button click or listbox touch...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.3.4 release
Hardware: All All
: medium normal
Assignee: Lionel Elie Mamane
URL:
Whiteboard: BSA target:4.1.0 target:4.0.4
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-18 19:57 UTC by Piotr
Modified: 2020-04-19 12:44 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Form Navigator screenshot - form structure (60.52 KB, image/png)
2013-04-22 07:43 UTC, Piotr
Details
test_db_mysql (12.36 KB, application/vnd.sun.xml.base)
2013-05-09 19:01 UTC, Piotr
Details
additional_explanation (127.82 KB, application/pdf)
2013-05-10 07:10 UTC, Piotr
Details
Form with subform, built in database, same bug (12.58 KB, application/vnd.sun.xml.base)
2013-05-10 10:41 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr 2013-04-18 19:57:28 UTC
Problem description: In the Form I change one of the values using listbox. Then I change field to textbox filled with multiple lines "Long Text". As I type the dikette remains grey and from the start You cannot save changes to database. I use mysql with jdbc connection. I changed to new driver but nothing changes. This error lasts since openoffice (It worked exactly the same).

Steps to reproduce:
1. Open form
2. Change one of the values
3. Change Long Text database type Text Field in Form.
4. See if diskette of the navigation below remains grey.

Current behavior:
You cannot save changes in some fields beacause Libre Office base does not see that it's changed.

Expected behavior:
All the changes are noticed by Libre Office base and you can save data changes
              
Operating System: Windows 7
Version: 3.6.5.2 release
Comment 1 Robert Großkopf 2013-04-20 17:15:11 UTC
Can't confirm this behavior with LO 3.5.7 and LO 4.0.3.1. Have created a "Long Text"-field, also an input-field in a form. Could change the content. The button for saving the new content will be activated, when the content has been changed.
LO 3.6.* is not available at this time at my PC. My system: OpenSUSE-Linux 32bit rpm-Linux.
Comment 2 Piotr 2013-04-22 07:36:40 UTC
It's not 100% reproducible. It happens like 1/10 times. Additionally it happens on Win 7 32 bit, Win 7 64bit, OpenOffice, Libre Office - all versions. One common thing is the database server: MySQL 5.1.48-community running on Windows XP. Everything else has changed. We use several computers to connect to this database. On all computers it is the same.
Once it happens You may type as long as You want but diskette is always grey and You can't save changes. After changing to next record and back again tha data remains from before the typing.
One more thing: It also happens to normal VARCHAR fields, but long text is the worst case.
Comment 3 Piotr 2013-04-22 07:43:07 UTC
Created attachment 78321 [details]
Form Navigator screenshot - form structure

I attach additionally the structure of the form as form navigation screenshot.
Comment 4 Julien Nabet 2013-05-04 21:08:40 UTC
Piotr: when you tell "Libre Office - all versions", do you mean you also tried last one, 4.0.2? (BTW 4.0.3 will be released in a few days)
Comment 5 Piotr 2013-05-04 21:12:23 UTC
Version 4.0.2 -> No. I did not try version 4 at all. I'm not sure if it is stable enough - sorry. But is there a serious chance that something in this matter has changed?
Comment 6 Julien Nabet 2013-05-04 21:18:05 UTC
4.0 is a major version. Now I can't assure the bug won't appear in 4.0.2 but this version is the recommended one. You may also wait for the 4.0.3 which will be released in few days as I said in my previous comment.
Moreover, you could give a try to some days for the test. It could be interesting to know if the bug is still there or not.

Now it's up to you :-)
Comment 7 Piotr 2013-05-06 14:49:37 UTC
Today I installed Libre Office 4.0.2.2 and..... The bug is still there :( 

By the way I noticed that 100% reproduction is to enter the record FOR THE FIRST TIME, press button  (I assigned macro to open file folder connected with  the record) and going to text field, libre does not recognize changes. 

Another observation is that I set a trigger (BEFORE UPDATE) in my database to insert a record in additional table every time the trigger is called (so when the main record is updated). Observation: After such situation no record is added (so the record in mysql database is never touched by Libre)
Comment 8 Julien Nabet 2013-05-08 07:17:53 UTC
Lionel: reading the last Piotr's comment, it makes me think about fdo#63398 (I put it in see also), is it right?
Comment 9 Piotr 2013-05-08 07:29:28 UTC
not quite:
1) It exists in all versions I know (not only 4) and openoffice.
2) I set the trigger IN THE DATABASE (not in the forms)
3) It happens not only if Macro is running. Before I had no macros at all in my forms and it still happened. I can switch the macros off -> it is the same.

I have also a feeling that it happens mostly when the form is in the background for a while (and particularly my macro openning file folder always put form in the background because it opened another application).
Comment 10 Lionel Elie Mamane 2013-05-08 07:52:41 UTC
(In reply to comment #7)

> By the way I noticed that 100% reproduction is to enter the record FOR THE
> FIRST TIME, press button  (I assigned macro to open file folder connected
> with  the record) and going to text field, libre does not recognize changes. 

You found a way to always reproduce? Great! That will allow us to reproduce the bug ourself and hopefully to fix it. However, I don't understand your reproduction instructions. Please clarify:

 - "enter record FOR THE FIRST TIME": is that adding a new record, as opposed
   to editing (modifying) an existing one?

 - "press button": press what button?

 - could you please attach a MySQL dump of an affected database and
   the .odb file used to connect to it?

   You can obviously create a "fresh" database with dummy data,
   if you don't want to show us / the whole world you data.
   As long as you get the issue with the database with the dummy data :)

(I don't think it is related to bug 63398.)
Comment 11 Piotr 2013-05-09 19:01:21 UTC
Created attachment 79059 [details]
test_db_mysql

OK!!! I managed to set up completely new simple database and form in LO and have exaclty the same effect :))))

How to:
1) Must have JDBC class in path
2) STart attached file for test database.
3) Enter password "lK2%hH1!", user "sql28360" should be stored  - some free mysql server on freemysqlhosting.net
4) Start form "ed klient" - the only one
5) change record pointer in the upper table to anything else but first record (only once!!! do not touch anything else)
6) Press a button to open information service on internet (I put www.onet.pl). It is not even a macro.
7) Internet browser opens. Take your time during browsing different pages. It must last for a while (1-2 minutes is enough)
8) with ALT-TAB return to the form
9) Not touching anything else start typing in the bottom field "Additional info" and observe the diskette button on bottom panel ;)

Keep the fingers crossed that reproduction works for You!
Comment 12 Piotr 2013-05-09 19:19:43 UTC
one more thing I forgot: If the bottom text field "Additional info" is below the screen move the screen BEFORE pressing the button. Do not touch ANYTHING ELSE after switch back to the form beside starting typing into this text field.
Comment 13 Lionel Elie Mamane 2013-05-10 06:08:27 UTC
(In reply to comment #11)

Cannot immediately reproduce on LibreOffice 3.5 on Debian GNU/Linux amd64.

> 5) change record pointer in the upper table to anything else but first
> record (only once!!! do not touch anything else)

There are several ways to do that, and maybe this happens with only one of them?

 - Click in the "left margin" of a record, selecting the whole record.
   The status line of the table says e.g. "Record 3 of 4 (1)".

 - Click in the first data column of a record, selecting only that cell
   (one column of one row).
   The status line of the table says e.g. "Record 3 of 4"

 - Use the arrows in the status line of the table.

 - Type a number in the status line of the table; where it says "1",
   e.g. put "3"

 - Use the arrow keys of the keyboard to go down

 - Press TAB repeatedly until one changes record

> 6) Press a button to open information service on internet (I put
> www.onet.pl). It is not even a macro.

I still don't understand what button I'm supposed to push. I don't see any "out of the ordinary" button in the form, and I don't understand how a button on the form would open a website without a macro.

> 9) Not touching anything else start typing in the bottom field "Additional
> info" and observe the diskette button on bottom panel ;)

So I have to click in the "add_info" field to put focus in it?


(In reply to comment #12)
> one more thing I forgot: If the bottom text field "Additional info" is below
> the screen move the screen BEFORE pressing the button.

For me, if I do that, the form moves back to top when I go back to ut and I have to scroll again.
Comment 14 Piotr 2013-05-10 07:10:52 UTC
Created attachment 79075 [details]
additional_explanation

Lionel,
I send additional explanation in form of screen shot with comments. For me it is 100% reproducible in this case. 
In ma case it is VERY important bug because people use the button to open specific outside information and than type it in database, but after all it is missing!!

Maybe it happens only on windows??
Is there a way to record screen?
Comment 15 Robert Großkopf 2013-05-10 08:36:25 UTC
I can confirm this bug.
The following happens:
You get back to the form. 
You move through the form with tabulators.
You click with the mouse in the field "add_info".
The counter of navigation-bar shows row 2 of 4 (I have chosen row 2 in the tablecontrol of the mainform). Notice: the counter doesn't change to the subform; in the subform is only row 1 of 1.
The Input of the field "add_info" isn't noticed by the form, because the GUI is waiting for an input in the mainform.

When moving with the tabulator through the form I notice, that every field of the subform is shown with row 2 of 4. You couldn't change everything in the subform, because the the GUI doesn't notice, that the cursor is in the subform. So this isn't a special bug of a special text-field. It's a bug of recognizing the position of the cursor when getting inside a form from other windows by Alt  Tab.

My System: OpenSUSE 12.3 32bit rpm. So I will change the platform to "All".
Also I could reproduce it with LO 3.3.4, LO 3.6.62. So I will change the Version to LO 3.3.4. Could be a bug since the beginning of LO.
Comment 16 Piotr 2013-05-10 10:12:51 UTC
Robert -> Thanx!
I change the importance to high, because it leads to DATA LOSS and occurs at every platforms. I thought it can be a specific bug on my database but it seems it affect most of the systems (maybe not everybody even notices that data is lost).

From the time I added the buttons (which always takes focus out of the form) it is very serious problem.
The buttons had to make work easier, but lead to additional problems...
Comment 17 Robert Großkopf 2013-05-10 10:41:10 UTC
Created attachment 79085 [details]
Form with subform, built in database, same bug

This isn't a special bug of MySQL. I have created a database with two tables. The tables are connected with a 1:1-relation. There are 4 rows in the table of the mainform. Every row of the mainform could only show one row of the table in the subform.
Now open the form. Press the button, which doesn't have any function. The navigation-bar changes from "row 1 of 4" to "row 1 of 1". It has been changed to the subform. Now press the tabulator-key. The cursor enters the first field of the subform. But at the same moment the navigation-bar changes to "row 1 of 4". Write something in the textfield. It couldn't be saved.
Comment 18 Lionel Elie Mamane 2013-05-10 10:45:30 UTC
OK, reproduced on 3.6 and 4.0 (my development trees).

Step 5 is not necessary for me, neither is "take your time", I can go directly back to the form after browser opens. Also, bug is still reproducible if I change the button's action to "None".

The crucial step seems to be to exit focus of MainForm to a button in SubForm. If I move the button to the MainForm, then bug is not reproducible anymore.
Comment 19 Piotr 2013-05-10 12:24:29 UTC
I add listbox. Button or listbox causes the same effect.
As for listbox only touching without changing value will cause this effect.
Comment 20 Lionel Elie Mamane 2013-05-11 22:26:33 UTC
Caused by the fix to https://issues.apache.org/ooo/show_bug.cgi?id=51621

When clicking on the button, in FmTextControlShell::controlActivated,
m_aControlActivationHandler is not called, because the button does
not serve any SFX slots, so "not useful to put the form shell on
top of the stack".

Execution continues and the button's "got focus" method activates
the its datafrom (subForm). So far so good.

However, when giving focus to a text control, m_aControlActivationHandler
is called, the form shell is not on top of the stack, so it is put there.
Which has as side-effect to activate the top dataform (main)... which is the
wrong one, since the text area belongs to the subform, not main.


By contrast, when moving directly to the text control,
_aControlActivationHandler is called, which (re)activates
the top (main) dataform and *after* that the subform is activated.
Comment 21 Commit Notification 2013-05-12 03:17:06 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=7fd1cc18130464a9f09cb7a866e88c4d52e4716d

fdo#63695 revert hackish fix to i#51621



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 22 Commit Notification 2013-05-15 08:56:30 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=66ca50016b8a65e67269026ca5b456fa4f8fa35e&h=libreoffice-4-0

fdo#63695 revert hackish fix to i#51621


It will be available in LibreOffice 4.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.