Download it now!
Bug 75339 - UI: No Error-Dialog appears, when Input is required in a Field of a Form trying to move with Tabulator to next Row
Summary: UI: No Error-Dialog appears, when Input is required in a Field of a Form tryi...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: Other Linux (All)
: high major
Assignee: Lionel Elie Mamane
URL:
Whiteboard: target:4.4.0 target:4.2.6 target:4.3.0.2
Keywords: regression
Depends on:
Blocks:
 
Reported: 2014-02-21 20:34 UTC by Robert Großkopf
Modified: 2014-06-24 19:06 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Database with a form, where all fields (except one) were set to "Input required" (20.84 KB, application/vnd.oasis.opendocument.base)
2014-02-21 20:34 UTC, Robert Großkopf
Details
New database, delete a value, try to save by tabbing through the form (20.87 KB, application/vnd.sun.xml.base)
2014-06-08 17:30 UTC, Robert Großkopf
Details
Dialog with Error-Message up to LO 4.1.* - lost since 4.2.* (42.07 KB, image/png)
2014-06-08 17:46 UTC, Robert Großkopf
Details
compare Reference< XColumn > instead of Reference< XInterface > (877 bytes, patch)
2014-06-24 08:51 UTC, Lionel Elie Mamane
Details
compare the references instead of comparing the .get() (690 bytes, patch)
2014-06-24 09:00 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2014-02-21 20:34:48 UTC
Created attachment 94531 [details]
Database with a form, where all fields (except one) were set to "Input required"

Open the attached database.
Open the form "Table_Input_required_GUI_and_SQL".
Delete, for example, the value in "Text" – no error appears, no saving is possible. LO seems to hang for the normal user. The dialog for an error ("Input required for filed "Name" ...) appears in all LO-Versions up to LO 4.1.*, doesn't appear since the first LO 4.2.*.
Comment 1 Julien Nabet 2014-06-08 15:43:22 UTC
On pc Debian x86-64 with 4.2.4 LO Debian package, I tried to reproduce this but the text displays "0" instead of "Hallo".

However with 4.2 sources updated some days ago, I don't have this problem and can't reproduce this.

Robert: could you give a try to the prerelease 4.2.5?
Comment 2 Robert Großkopf 2014-06-08 17:15:50 UTC
The report isn't complete:
The dialog appears for everybody, who will use the navigationbar. 

Most Base-users do not use the navigation-bar. They will change values in a form and switch with tabulator and arrow-key to the next row.

With navigationbar and pressing the button for saving the row it works right. But it doesn't work right while using the tabulator or the arrow-keys.

I will change the title a little bit.
Comment 3 Robert Großkopf 2014-06-08 17:30:50 UTC
Created attachment 100684 [details]
New database, delete a value, try to save by tabbing through the form

Open the form "Table_Input_required_GUI_and_SQL". Remove the word "Hello". Move through the form by using the tabulator or arrow-keys to the next row. No error appears.

Works by using the navigationbar. Works with tabulator in all versions before LO 4.2.*
Comment 4 Robert Großkopf 2014-06-08 17:46:14 UTC
Created attachment 100685 [details]
Dialog with Error-Message up to LO 4.1.* - lost since 4.2.*

Let me add an information. The dialog for the error-message in 4.1.* and all versions before is translated to German (my first language). It informs normal users where an input is required.

The dialog, which appears since 4.2.* when trying to save through the navigationbar is the same dialog, which appears, when you try to save a row directly in the table - not in the form. The message comes from the database. It shows the whole SQL-Code. The translated short dialog is missed since 4.2.*
Comment 5 Julien Nabet 2014-06-22 20:56:29 UTC
Sorry for the delay Robert.
I could reproduce the pb with master sources updated yesterday.

I noticed this on console logs:
warn:legacy.osl:5337:1:svx/source/form/formcontrolling.cxx:464: FormControllerHelper::errorOccurred: two errors during one operation?
but indeed, no popup error.
Comment 6 Julien Nabet 2014-06-23 19:15:24 UTC
According to description, regression.
So regression + usability impact, I increase  the importance.
Comment 7 Commit Notification 2014-06-23 20:15:39 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

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

Resolves fdo#75339 : No Error-Dialog appears in specific cases in Base



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 8 Lionel Elie Mamane 2014-06-24 08:10:22 UTC
Stephan? I'm having a difficulty with yet another subtelty of Reference in treating this bug.

Consider this code (file svx/source/form/formcontroller.cxx):

308	    bool lcl_isBoundTo( const Reference< XPropertySet >& _rxControlModel, const Reference< XInterface >& _rxNormDBField )
309	    {
310	        Reference< XInterface > xNormBoundField( _rxControlModel->getPropertyValue( FM_PROP_BOUNDFIELD ), UNO_QUERY );
311	        return ( xNormBoundField.get() == _rxNormDBField.get() );
312	    }

Consider this gdb trace:

Breakpoint 5, svxform::(anonymous namespace)::lcl_isBoundTo (
    _rxControlModel=uno::Reference to (frm::FormattedFieldColumn *) 0x5f0f128, 
    _rxNormDBField=uno::Reference to (dbaccess::ORowSetDataColumn *) 0x2e44a88)
    at /home/master/src/libreoffice/workdirs/libreoffice-4-4/svx/source/form/formcontroller.cxx:311
(gdb) print xNormBoundField.get()
$50 = (dbaccess::ORowSetDataColumn *) 0x2e448d0
(gdb) print _rxNormDBField.get()
$51 = (dbaccess::ORowSetDataColumn *) 0x2e448d0
(gdb) print xNormBoundField
$52 = uno::Reference to (dbaccess::ORowSetDataColumn *) 0x2e448d0
(gdb) print _rxNormDBField
$53 = uno::Reference to (dbaccess::ORowSetDataColumn *) 0x2e44a88
(gdb) set print pretty off
(gdb) set print object off
(gdb) print _rxNormDBField.get()
$54 = (com::sun::star::uno::XInterface *) 0x2e44a88
(gdb) print xNormBoundField.get()
$55 = (com::sun::star::uno::XInterface *) 0x2e448d0
(gdb) finish
Run till exit from #0  svxform::(anonymous namespace)::lcl_isBoundTo (
    _rxControlModel=uno::Reference to (frm::FormattedFieldColumn *) 0x5f0f128, 
    _rxNormDBField=uno::Reference to (dbaccess::ORowSetDataColumn *) 0x2e44a88)
    at /home/master/src/libreoffice/workdirs/libreoffice-4-4/svx/source/form/formcontroller.cxx:311
0x00007f88104df38d in svxform::ColumnInfoCache::initializeControls (this=0x2ef9ae0, 
    _rControls=uno::Sequence of length 1 = {...})
    at /home/master/src/libreoffice/workdirs/libreoffice-4-4/svx/source/form/formcontroller.cxx:378
Value returned is $56 = false


The expectation of the code is that lcl_isBoundTo returns "true", but it returns false. Has something changed in 4.2 (compared to 4.1 and earlier) that breaks this assumption? How can we achieve the effect the code expects? I don't think we can commit to one particular implementation of "Column Model".
Comment 9 Lionel Elie Mamane 2014-06-24 08:51:27 UTC
Created attachment 101649 [details]
compare Reference< XColumn > instead of Reference< XInterface >

This patch seems to work. My understanding is that instead of using an ambiguous base, we use a non-ambiguous base and then pointers into the same object are to the same entry in the vtable (because there is only one) instead of the risk of being into different entries for the ambiguous base in the vtable.
Comment 10 Lionel Elie Mamane 2014-06-24 09:00:45 UTC
Created attachment 101652 [details]
compare the references instead of comparing the .get()

This patch also works... Aha, this seems to be thanks to special-case code in "inline bool BaseReference::operator == ( XInterface * pInterface ) const" (file include/com/sun/star/uno/Reference.hxx):

    if (_pInterface == pInterface)
        return true;
    try
    {
        // only the query to XInterface must return the same pointer if they belong to same objects
        Reference< XInterface > x1( _pInterface, UNO_QUERY );
        Reference< XInterface > x2( pInterface, UNO_QUERY );
        return (x1._pInterface == x2._pInterface);
    }

                             
Stephan? Your opinion? Is this patch 100% robust, or should we go with the other patch (comparing XColumn pointers)?
Comment 11 Commit Notification 2014-06-24 09:46:42 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

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

fdo#75339: Substituting XInterface* eq. for object eq. requires queryInterface



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 Stephan Bergmann 2014-06-24 09:57:56 UTC
(In reply to comment #10)
> Stephan? Your opinion? Is this patch 100% robust, or should we go with the
> other patch (comparing XColumn pointers)?

Oh, sorry, didn't notice you were working on this in parallel with me.  Yes, checking UNO object equality is achieved by checking equality of css.uno.XInterface pointers obtained via queryInterface, so your attachment 101652 [details] would work (while attachment 101649 [details] would need not, in general).  But I meanwhile pushed a slightly different fix that simply reverts the regression that introduced this problem (the original code at least pretended to be more efficient, by computing the normalized xCol->xColumn XInterface ptr less often---of course at the expense of making the code more error prone to maintenance "improvements," oh my).
Comment 13 Stephan Bergmann 2014-06-24 10:30:41 UTC
(In reply to comment #11)
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=f8115ce72dad45b82b044d9c8f5c253d0514574d
> 
> fdo#75339: Substituting XInterface* eq. for object eq. requires
> queryInterface

requested backports to libreoffice-4-2 (<https://gerrit.libreoffice.org/#/c/9875/>) and libreoffice-4-3 (<https://gerrit.libreoffice.org/#/c/9874/>)
Comment 14 Julien Nabet 2014-06-24 11:23:45 UTC
Lionel: just to be sure and for not making a mistake, are we ok that http://cgit.freedesktop.org/libreoffice/core/commit/?id=701bbaf93f0d31ae73e94e0cebccb1cfba0e5882 still needs to be reverted?
Comment 15 Commit Notification 2014-06-24 15:27:31 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a07f2fbc482c2644c4a80287b9139585150b30d1&h=libreoffice-4-2

fdo#75339: Substituting XInterface* eq. for object eq. requires queryInterface


It will be available in LibreOffice 4.2.6.

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 Commit Notification 2014-06-24 15:27:45 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=12167e566c6c27b7bcd43e322f35ed6c799175e8&h=libreoffice-4-3

fdo#75339: Substituting XInterface* eq. for object eq. requires queryInterface


It will be available in LibreOffice 4.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 17 Lionel Elie Mamane 2014-06-24 17:08:59 UTC
(In reply to comment #14)
> Lionel: just to be sure and for not making a mistake, are we ok that
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=701bbaf93f0d31ae73e94e0cebccb1cfba0e5882 still needs to be reverted?

Well, unless it fixes scenarios that I did not test, yes, please revert it.
Comment 18 Commit Notification 2014-06-24 17:17: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=402e0c0a679dd4da2b1767d959be9aa364c1878d

fdo#75339 object comparison by reference, not pointer



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 2014-06-24 18:04:12 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

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

Revert "Resolves fdo#75339 : No Error-Dialog appears in specific cases..."



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 20 Julien Nabet 2014-06-24 19:06:35 UTC
(In reply to comment #17)
> (In reply to comment #14)
> > Lionel: just to be sure and for not making a mistake, are we ok that
> > http://cgit.freedesktop.org/libreoffice/core/commit/
> > ?id=701bbaf93f0d31ae73e94e0cebccb1cfba0e5882 still needs to be reverted?
> 
> Well, unless it fixes scenarios that I did not test, yes, please revert it.

Done, see http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa7b9062f68b1cfdd76ad1987bde5eed170ed6cf
(I reverted too Stephan's commit about include, since it's useless now)

Thank you both of you! :)