Bug 46579 - Form fields 'Image Button' do not work in Forms
Summary: Form fields 'Image Button' do not work in Forms
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.1 target:7.0.5
Keywords:
: 89169 (view as bug list)
Depends on:
Blocks: Base-Images
  Show dependency treegraph
 
Reported: 2012-02-24 09:03 UTC by Robert Großkopf
Modified: 2021-02-05 11:04 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Open the form and try the graphical buttons, which are added. (20.74 KB, application/vnd.sun.xml.base)
2012-02-24 11:05 UTC, Robert Großkopf
Details
Enhanced sample document (24.34 KB, application/vnd.sun.xml.base)
2012-02-25 00:39 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2012-02-24 09:03:03 UTC
When trying to set an action to a graphical button nothing happens. Only the reset-function will work.
I could not find this bug, but it won't work also in OOo 3.3.
Comment 1 Rainer Bielefeld Retired 2012-02-24 10:35:55 UTC
NOT reproducible with and first sample from "Bug 37024 - UI: WEB-View for Form layout no longer available " <https://bugs.freedesktop.org/show_bug.cgi?id=37024> I tried Navigation toolbar, everything worked fine. To be honest, I have no idea what problem reporter is talking about.

This is not a valid bug report, any useful information is missing. Robert, you should know better, please contribute additional information concerning your OS, LibO version, due to Bug 44204#C1!
Comment 2 Robert Großkopf 2012-02-24 11:05:29 UTC
Created attachment 57604 [details]
Open the form and try the graphical buttons, which are added.

I have not realised that you could think: graphical buttons are the navigation-bar and so on. These buttons are control-fields of a form. And these buttons wont work under Linux-rpm in LibreOffice 3.3.4 and in LibreOffice 3.5. And these Buttons wont't work (not our problem, you might think) in OOo 3.3 under Linux-rpm, Windows and Mac.
I can not realise that nobody had recognised it before.

Robert
Comment 3 Rainer Bielefeld Retired 2012-02-25 00:27:08 UTC
[Reproducible] with "LibreOffice Portable 3.3.0  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:6) tag libreoffice-3.3.0.4]" 

Also a problem  with 3.4.5, 3.5.0

Still [Reproducible] with "LOdev 3.6.0alpha0+  English UI/Locale [Build ID: aa7e105-b2dd236-9eed775-d06f752-4dba2d1 (libreoffice-3-5-branch-point)]"  {Win-x86@9-Voreppe Win32 pull time 2012-02-14 16:17:23}. OS: German WIN7 Home Premium (64bit)  

Inherited from OOo, also a Problem with OOo 3.1.1, 3.3, 3.4Beta; I did not find an AOOo Issue.

I attached a modified version of reporter's database showing that normal Push Buttons work as expected.

Lionel: 
One for you? Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug.
Comment 4 Rainer Bielefeld Retired 2012-02-25 00:39:59 UTC
Created attachment 57621 [details]
Enhanced sample document

Enhanced sample document additionally shows that "normal" buttons work fine.
Comment 5 Julien Nabet 2014-10-12 09:14:02 UTC
For the record, on pc Debian x86-64 with master sources updated yesterday, I could reproduce this.
Comment 6 Alex Thurgood 2015-01-03 17:39:15 UTC Comment hidden (no-value)
Comment 7 Alex Thurgood 2015-02-06 14:52:39 UTC
*** Bug 89169 has been marked as a duplicate of this bug. ***
Comment 8 QA Administrators 2017-01-03 19:41:04 UTC Comment hidden (obsolete)
Comment 9 Robert Großkopf 2017-01-04 07:16:00 UTC
Bug still exist in
Version: 5.2.4.2
Build-ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0
CPU-Threads: 4; BS-Version: Linux 4.1; UI-Render: Standard; VCL: kde4; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

Also tested with LO 5.4.0.0.alpha0. Same behavior. Nothing happens if I click on any "ImageButton" of the form.
Comment 10 Robert Großkopf 2017-01-04 11:14:35 UTC
OK, I have found a workaround:
You could set the action to 
"Open document/web page"
and then type for URL
.uno:NextRecord
... so you get the action "Next Record"

Seems the actions have simply been forgotten ...
Comment 11 QA Administrators 2018-02-08 03:35:07 UTC Comment hidden (obsolete)
Comment 12 Julien Nabet 2018-02-08 08:03:23 UTC
On pc Debian x86-64 with master sources updated yesterday, I can still reproduce this.
Comment 13 QA Administrators 2019-02-09 03:44:38 UTC Comment hidden (obsolete)
Comment 14 Robert Großkopf 2019-02-09 08:48:57 UTC
Bug still exists with LO 6.1.5.2 on OpenSUSE 15, 64bit rpm Linux.
Comment 15 Tom 2020-02-14 10:56:07 UTC
Bug still exists in LO 6.3.4  on Windows 10 (64 bits). Database-type does not matter. Unfortunately the suggested workaround does not work either (in my case): The settings are accepted when editing the form, but nothing happens when used.
Comment 16 Tom 2020-02-14 12:45:57 UTC Comment hidden (obsolete)
Comment 17 Julien Nabet 2020-11-29 10:37:55 UTC
Lionel: following Robert's comment about using ".uno:NextRecord", I gave a try with this patch:
diff --git a/extensions/source/propctrlr/pushbuttonnavigation.cxx b/extensions/source/propctrlr/pushbuttonnavigation.cxx
index 3d1bf748c712..786ef8862eb6 100644
--- a/extensions/source/propctrlr/pushbuttonnavigation.cxx
+++ b/extensions/source/propctrlr/pushbuttonnavigation.cxx
@@ -43,7 +43,7 @@ namespace pcr
         {
             ".uno:FormController/moveToFirst",
             ".uno:FormController/moveToPrev",
-            ".uno:FormController/moveToNext",
+            ".uno:NextRecord",
             ".uno:FormController/moveToLast",
             ".uno:FormController/saveRecord",
             ".uno:FormController/undoRecord",
diff --git a/forms/source/inc/frm_strings.hxx b/forms/source/inc/frm_strings.hxx
index 06d3f8cb148b..af69996206c5 100644
--- a/forms/source/inc/frm_strings.hxx
+++ b/forms/source/inc/frm_strings.hxx
@@ -274,7 +274,7 @@ namespace frm
     #define URL_FORM_RECORDCOUNT  ".uno:FormController/RecordCount"
     #define URL_RECORD_FIRST      ".uno:FormController/moveToFirst"
     #define URL_RECORD_PREV       ".uno:FormController/moveToPrev"
-    #define URL_RECORD_NEXT       ".uno:FormController/moveToNext"
+    #define URL_RECORD_NEXT       ".uno:NextRecord"
     #define URL_RECORD_LAST       ".uno:FormController/moveToLast"
     #define URL_RECORD_SAVE       ".uno:FormController/saveRecord"
     #define URL_RECORD_UNDO       ".uno:FormController/undoRecord"
diff --git a/svx/source/inc/fmurl.hxx b/svx/source/inc/fmurl.hxx
index a354eae59e84..bd6c9837e047 100644
--- a/svx/source/inc/fmurl.hxx
+++ b/svx/source/inc/fmurl.hxx
@@ -24,7 +24,7 @@
 #define FMURL_FORM_RECORDCOUNT             ".uno:FormController/RecordCount"
 #define FMURL_RECORD_MOVEFIRST             ".uno:FormController/moveToFirst"
 #define FMURL_RECORD_MOVEPREV              ".uno:FormController/moveToPrev"
-#define FMURL_RECORD_MOVENEXT              ".uno:FormController/moveToNext"
+#define FMURL_RECORD_MOVENEXT              ".uno:NextRecord"
 #define FMURL_RECORD_MOVELAST              ".uno:FormController/moveToLast"
 #define FMURL_RECORD_MOVETONEW             ".uno:FormController/moveToNew"
 #define FMURL_RECORD_UNDO                  ".uno:FormController/undoRecord"

Then I modified the form to use next record for the image control since it was broken with the patch then it worked!

So do you think it's the right way or should we stick to urls like:
.uno:FormController/<action> ?
I mean, I'm not sure these uno/FormController work in other cases so even if the each exiting forms will have to be modified, since it didn't work at first place, I think it might be the right move.
Comment 18 Lionel Elie Mamane 2020-11-30 06:54:34 UTC
Wow, that's a strange bug indeed.

Text button and image button seem to have quite different implementations, not sure why.

I see that text buttons, in forms/source/component/Button.cxx, have some special treatment of URLs starting with ".uno:FormController/", in function OButtonControl::getModelUrlFeatureId:

    // are we a URL button?
    if ( eButtonType == FormButtonType_URL )
    {
        // is it a feature URL?
        if ( isFormControllerURL( sUrl ) )
        {
            nFeatureId = OFormNavigationMapper::getFeatureId( sUrl );
        }
    }

My guess is that the same treatment must happen for image buttons, but doesn't. Probably should happen either somewhere in ImageButton.cxx or in the parent class clickableimage.cxx
Comment 19 Julien Nabet 2020-11-30 12:27:06 UTC
(In reply to Lionel Elie Mamane from comment #18)
> ...
> My guess is that the same treatment must happen for image buttons, but
> doesn't. Probably should happen either somewhere in ImageButton.cxx or in
> the parent class clickableimage.cxx

Thank you for the feedback. I'll take a look.
What I liked in the patch I quoted is the fact we could use same uno commands as others. If we fix this bug by finding the way to deal with .uno:FormController/*, we won't be able to remove these since it'll bring some compatibility regression.
Comment 20 Julien Nabet 2020-12-01 23:10:47 UTC
Lionel: I finally found the missing element for clickable image.
dispatch/interceptor part was difficult to track down.
I submitted https://gerrit.libreoffice.org/c/core/+/107037
Comment 21 Julien Nabet 2020-12-02 12:21:35 UTC
(In reply to Julien Nabet from comment #20)
> Lionel: I finally found the missing element for clickable image.
> dispatch/interceptor part was difficult to track down.
> I submitted https://gerrit.libreoffice.org/c/core/+/107037

Sorry Lionel the comment of my patch didn't explain anything, I was quite tired yesterday and eager to submit the patch :-)

Let's start with non image button which work.
When entering the form, the specific dispatch mechanism for these urls is prepared:
Thread 1 "soffice.bin" hit Breakpoint 1, frm::OFormNavigationHelper::queryDispatch (this=0x7781dc8, _rURL=...) at forms/source/helper/formnavigation.cxx:263
263	        return m_pFeatureInterception->queryDispatch( _rURL );
(gdb) p _rURL
$1 = (const com::sun::star::util::URL &) @0x7783208: {Complete = ".uno:FormController/moveToFirst", Main = ".uno:FormController/moveToFirst", Protocol = ".uno:", User = "", Password = "", Server = "", 
  Port = 0, Path = "FormController/moveToFirst", Name = "", Arguments = "", Mark = ""}
(gdb) bt
#0  frm::OFormNavigationHelper::queryDispatch(com::sun::star::util::URL const&) (this=0x7781dc8, _rURL=...) at forms/source/helper/formnavigation.cxx:263
#1  0x00007f85f9087ec1 in frm::OFormNavigationHelper::connectDispatchers() (this=0x7781dc8) at forms/source/helper/formnavigation.cxx:200
#2  0x00007f85f9087353 in frm::OFormNavigationHelper::updateDispatches() (this=0x7781dc8) at forms/source/helper/formnavigation.cxx:146
#3  0x00007f85f8eef7ee in frm::OButtonControl::modelFeatureUrlPotentiallyChanged() (this=0x7781c80) at forms/source/component/Button.cxx:623
#4  0x00007f85f8eef701 in frm::OButtonControl::setModel(com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> const&) (this=0x7781c80, _rxModel=
    uno::Reference to (UnoControlButtonModel *) 0x393af28) at forms/source/component/Button.cxx:607
#5  0x00007f864a52ac26 in sdr::contact::(anonymous namespace)::ControlHolder::setModel(com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> const&) const
    (this=0x7fffa2d6e700, _m=uno::Reference to (UnoControlButtonModel *) 0x393af28) at svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:187

Notice URL:
{Complete = ".uno:FormController/moveToFirst", Main = ".uno:FormController/moveToFirst", Protocol = ".uno:", User = "", Password = "", Server = "", 
  Port = 0, Path = "FormController/moveToFirst", Name = "", Arguments = "", Mark = ""}

It's also during form opening that the method "getModelUrlFeatureId" you quoted in your previous comment is called:
#0  frm::OButtonControl::getModelUrlFeatureId() const (this=0x73d2820) at forms/source/component/Button.cxx:655
#1  0x00007f85f8eef787 in frm::OButtonControl::modelFeatureUrlPotentiallyChanged() (this=0x73d2820) at forms/source/component/Button.cxx:618
#2  0x00007f85f8eef701 in frm::OButtonControl::setModel(com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> const&)
    (this=0x73d2820, _rxModel=uno::Reference to (UnoControlButtonModel *) 0x3e49c88) at forms/source/component/Button.cxx:607
#3  0x00007f864a52ac26 in sdr::contact::(anonymous namespace)::ControlHolder::setModel(com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> const&) const
    (this=0x7fffa2d6e700, _m=uno::Reference to (UnoControlButtonModel *) 0x3e49c88) at svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:187

Then once in the form, each click on one of these button calls:
#0  frm::OFormNavigationHelper::dispatch(short) const (this=0x7784578, _nFeatureId=5) at forms/source/helper/formnavigation.cxx:287
#1  0x00007f85f8eeeef3 in frm::OButtonControl::actionPerformed_Impl(bool, com::sun::star::awt::MouseEvent const&) (this=0x7784430, _bNotifyListener=false, _rEvt=...) at forms/source/component/Button.cxx:498
#2  0x00007f85f8eeed58 in frm::OButtonControl::OnClick(void*) (this=0x7784430) at forms/source/component/Button.cxx:478
#3  0x00007f85f8eee5c0 in frm::OButtonControl::LinkStubOnClick(void*, void*) (instance=0x7784430, data=0x0) at forms/source/component/Button.cxx:429
#4  0x00007f864739e9e8 in Link<void*, void>::Call(void*) const (this=0x6e1ec78, data=0x0) at include/tools/link.hxx:111
#5  0x00007f864739abee in ImplHandleUserEvent(ImplSVEvent*) (pSVEvent=0x6e1ec70) at vcl/source/window/winproc.cxx:1990


Now, let's take a look at image button which doesn't work.
When opening form there's some preparation with:
#0  frm::OImageButtonModel::describeFixedProperties(com::sun::star::uno::Sequence<com::sun::star::beans::Property>&) const (this=0x6f92d40, _rProps=empty uno::Sequence)
    at forms/source/component/ImageButton.cxx:78
#1  0x00007f85f8fd2c7c in frm::OControlModel::describeFixedAndAggregateProperties(com::sun::star::uno::Sequence<com::sun::star::beans::Property>&, com::sun::star::uno::Sequence<com::sun::star::beans::Property>&) const (this=0x6f92d60, _out_rFixedProperties=empty uno::Sequence, _out_rAggregateProperties=empty uno::Sequence) at forms/source/component/FormComponent.cxx:1040
#2  0x00007f85f9070f4c in frm::PropertyBagHelper::impl_ts_getArrayHelper() const (this=0x6f92ec8) at forms/source/component/propertybaghelper.cxx:154
#3  0x00007f85f8f6e7a5 in frm::PropertyBagHelper::getInfoHelper() const (this=0x6f92ec8) at forms/source/inc/propertybaghelper.hxx:112
#4  0x00007f85f8fd2e9e in frm::OControlModel::getInfoHelper() (this=0x6f92d60) at forms/source/component/FormComponent.cxx:1056
#5  0x00007f85f8fd2dde in frm::OControlModel::getPropertySetInfo() (this=0x6f92d60) at forms/source/component/FormComponent.cxx:1051
#6  0x00007f85f8fd2e6d in non-virtual thunk to frm::OControlModel::getPropertySetInfo() () at forms/source/component/FormComponent.cxx:1051
#7  0x00007f8643d7efc2 in xmloff::OControlImport::createElement() (this=0x3e6e210) at xmloff/source/forms/elementimport.cxx:1039

and each click on image button is done here:
Thread 1 "soffice.bin" hit Breakpoint 5, frm::OClickableImageBaseControl::actionPerformed_Impl (this=0x6e27910, bNotifyListener=false, rEvt=...) at forms/source/component/clickableimage.cxx:330
330	                        xDisp->dispatch( aHyperLink, aProps );
(gdb) bt
#0  frm::OClickableImageBaseControl::actionPerformed_Impl(bool, com::sun::star::awt::MouseEvent const&) (this=0x6e27910, bNotifyListener=false, rEvt=...) at forms/source/component/clickableimage.cxx:330
#1  0x00007f85f9027245 in frm::OImageButtonControl::mousePressed(com::sun::star::awt::MouseEvent const&) (this=0x6e27910, e=...) at forms/source/component/ImageButton.cxx:207
#2  0x00007f8649721097 in MouseListenerMultiplexer::mousePressed(com::sun::star::awt::MouseEvent const&) (this=0x783b738, evt=...) at toolkit/source/helper/listenermultiplexer.cxx:106
#3  0x00007f8649721097 in MouseListenerMultiplexer::mousePressed(com::sun::star::awt::MouseEvent const&) (this=0x6e2ebc8, evt=...) at toolkit/source/helper/listenermultiplexer.cxx:106
#4  0x00007f86494cda84 in VCLXWindow::ProcessWindowEvent(VclWindowEvent const&)::$_2::operator()() const (this=0x79f44c0) at toolkit/source/awt/vclxwindow.cxx:726

let's take a look at URL:
(gdb) p aHyperLink
$3 = {Complete = ".uno:OpenHyperlink", Main = ".uno:OpenHyperlink", Protocol = ".uno:", User = "", Password = "", Server = "", Port = 0, Path = "OpenHyperlink", Name = "", Arguments = "", Mark = ""}

all the info are in the second arg of "dispatch", "aProps":
(gdb) p aProps
$4 = uno::Sequence of length 3 = {{Name = "URL", Handle = 0, Value = uno::Any("string": ".uno:FormController/moveToNext"), State = com::sun::star::beans::PropertyState::PropertyState_DIRECT_VALUE}, {
    Name = "FrameName", Handle = 0, Value = uno::Any("string": "_blank"), State = com::sun::star::beans::PropertyState::PropertyState_DIRECT_VALUE}, {Name = "Referer", Handle = 0, 
    Value = uno::Any("string": ""), State = com::sun::star::beans::PropertyState::PropertyState_DIRECT_VALUE}}

Now let's take a look at m_pFeatureInterception declared the same way as ::std::unique_ptr< ControlFeatureInterception > in forms/source/inc/formnavigation.hxx and forms/source/component/clickableimage.hxx

ControlFeatureInterception is a "helper class for controls which allow some of their features to be intercepted"  (see https://opengrok.libreoffice.org/xref/core/forms/source/inc/controlfeatureinterception.hxx?r=f0c8312b#48)

(Argh, I must go back to work, I'll keep on later)
Comment 22 Julien Nabet 2020-12-02 20:01:07 UTC
Let's go on with m_pFeatureInterception which is ControlFeatureInterception.
This last one is initialized with param
- m_xORB (css::uno::Reference< css::uno::XComponentContext >) in formnavigation.cxx (the OK case)
- _rxFactory in clickableimage.cxx (the KO case)
...
Then the more I try to understand the rest, the more I got lost with all these dispatch, m_xORB, references, ...
The only thing I'm sure is the patch made this work.
I'll push this one on master and let people give it a try. If someone complains about it, don't hesitate to revert.
I'm quite fed up of all these tricky mechanisms in some parts of LO.
Comment 23 Commit Notification 2020-12-02 20:02:58 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/07be45d03f80fa681c697ca9f5a13084a81c7a26

tdf#46579: fix form fields 'Image Button' in Forms

It will be available in 7.2.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 24 Commit Notification 2020-12-03 17:29:57 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/6b5ca41c5d78e6a45f7a39d99c5a7ae283d243de

tdf#46579: fix form fields 'Image Button' in Forms

It will be available in 7.1.0.0.beta2.

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

Affected users are encouraged to test the fix and report feedback.
Comment 25 Commit Notification 2021-01-16 00:48:13 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/45963cfb6b453cf18aaa7534f20c35a38975dc89

tdf#46579: fix form fields 'Image Button' in Forms

It will be available in 7.0.5.

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

Affected users are encouraged to test the fix and report feedback.
Comment 26 Commit Notification 2021-02-04 20:21:23 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a444a8dd40cf7035c44ee8ef168be2b3e3144c86

tdf#140151: revert fix for tdf#46579 which caused regression

It will be available in 7.2.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 27 Julien Nabet 2021-02-04 20:25:20 UTC
Patch caused regression (see tdf#140151).
So I reverted it on master, and the revert waits for review for 7.1 and 7.0 branches.
No idea at all what's the pb of regression.
=> revert back to NEW and uncc myself.
Comment 28 Commit Notification 2021-02-05 09:34:12 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/9567639d6a649cffc9f1a965a11b5b202b241179

tdf#140151: revert fix for tdf#46579 which caused regression

It will be available in 7.1.1.

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

Affected users are encouraged to test the fix and report feedback.
Comment 29 Commit Notification 2021-02-05 11:04:39 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/2a27ff2190a40afe806bbf3577b641390047e209

tdf#140151: revert fix for tdf#46579 which caused regression

It will be available in 7.0.5.

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

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