Bug 146150 - Use dispatch command instead of numerical ID for the UNO commands
Summary: Use dispatch command instead of numerical ID for the UNO commands
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: reviewed:2022 target:7.6.0 target:24.2.0
Keywords: difficultyMedium, easyHack, skillCpp, skillJava, topicCleanup
Depends on:
Blocks: Dev-related
  Show dependency treegraph
 
Reported: 2021-12-09 14:55 UTC by Hossein
Modified: 2023-09-25 11:04 UTC (History)
5 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 Hossein 2021-12-09 14:55:28 UTC
If you look at this wiki page:

Development/DispatchCommands
https://wiki.documentfoundation.org/Development/DispatchCommands

it contains a list of UNO commands extracted from some version of the LibreOffice code. Each of these commands has its own unique ID, called "Resource ID" or "Slot ID" (SID).

For example:

SID:                5502
SID URL:            "slot:5502"
Dispatch command:   ".uno:SaveAs"
Symbolic constant:  SID_SAVEASDOC 

In some parts of the code, you can see that instead of the using the dispatch command, the equivalent SID is used. This can cause problems, because:

1. One may use wrong SID mistakenly:
https://git.libreoffice.org/core/+/1aa57f44c0d37ef23551943a64211dea17903873

2. The SID may change because of some problems or technical issues:
https://git.libreoffice.org/core/+/8ea9a8bc43ea054521a44dc8e3bc537110ca9e33

Some of the instances can be found using:

    git grep -e slot:[0-9]

So, a better approach would be using dispatch commands instead of the SID URLs. This task is defined to use "dispatch command" instead of "numerical ID" for the UNO commands. A sample conversion would be:

    "slot:5502" -> ".uno:SaveAs"
Comment 1 Shivam Jha 2021-12-11 09:28:18 UTC
Hi, I would like to work on this issue. I ran the grep command that you mentioned in your report and found a couple of java files. For example this one: framework/qa/complex/contextMenuInterceptor/ContextMenuInterceptor.java which uses the following code:
 // initialize root menu entry "Help"
               xRootMenuEntry.setPropertyValue("Text", "Help");
                xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410");
                xRootMenuEntry.setPropertyValue("HelpURL", "5410");
                xRootMenuEntry.setPropertyValue("SubContainer",  xSubMenuContainer);
                xRootMenuEntry.setPropertyValue("Image", myBitmap);


Question 1:
Does this report affects the above code? 
If yes, 
Question2: What would be the equivalent call to xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); in this case?
Comment 2 Mike Kaganski 2021-12-12 08:34:23 UTC
(In reply to Shivam Jha from comment #1)
> Question2: What would be the equivalent call to
> xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); in this case?

Note that the wiki page mentioned in comment 0 has history, which starts on 2015; it has some (not all) historical values there, that changed over time, and now are different. So e.g. 5410 may be found there, if you look at the last of 2015's initial set commits to that page.

And that is exactly why the numeric codes of slots should not change, and hence the answer to Question 1 is definitely yes.
Comment 3 Mike Kaganski 2021-12-12 08:56:01 UTC
(In reply to Mike Kaganski from comment #2)
> And that is exactly why the numeric codes of slots should not change

Oh sorry, got distracted - it was meant to say "And that is exactly why the numeric codes of slots should not be used - that may change"...
Comment 4 Shivam Jha 2021-12-12 09:19:45 UTC
(In reply to Mike Kaganski from comment #2)
> (In reply to Shivam Jha from comment #1)
> > Question2: What would be the equivalent call to
> > xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); in this case?
> 
> Note that the wiki page mentioned in comment 0 has history, which starts on
> 2015; it has some (not all) historical values there, that changed over time,
> and now are different. So e.g. 5410 may be found there, if you look at the
> last of 2015's initial set commits to that page.
> 
> And that is exactly why the numeric codes of slots should not change, and
> hence the answer to Question 1 is definitely yes.

So I looked through the history: https://wiki.documentfoundation.org/index.php?title=Development/DispatchCommands&oldid=114486 and found that equivalent uno command for slot:5410 is .uno:HelpMenu
Does that mean I just have to replace xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); with xRootMenuEntry.setPropertyValue("CommandURL", ".uno:HelpMenu"); ? Or the property name (The first parameter) will change if we want to use a uno command instead of the slot value?
Comment 5 Mike Kaganski 2021-12-12 11:05:22 UTC
(In reply to Shivam Jha from comment #4)
> equivalent uno command for slot:5410 is .uno:HelpMenu
> Does that mean I just have to replace
> xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); with
> xRootMenuEntry.setPropertyValue("CommandURL", ".uno:HelpMenu"); ? Or the
> property name (The first parameter) will change if we want to use a uno
> command instead of the slot value?

I don't know what Hossein thinks about it, but I would assume this to be your homework. Generally any change needs testing if it works as intended, so I'd assume that you run the code (maybe that would be the hardest part of the hack), and check if it worked correctly before (it should not); then test is simple replacement of value would fix it.
Comment 6 Hossein 2021-12-12 11:57:05 UTC
(In reply to Mike Kaganski from comment #5)
> (In reply to Shivam Jha from comment #4)
> > equivalent uno command for slot:5410 is .uno:HelpMenu
> > Does that mean I just have to replace
> > xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); with
> > xRootMenuEntry.setPropertyValue("CommandURL", ".uno:HelpMenu"); ? Or the
> > property name (The first parameter) will change if we want to use a uno
> > command instead of the slot value?
> 
> I don't know what Hossein thinks about it, but I would assume this to be
> your homework. Generally any change needs testing if it works as intended,
> so I'd assume that you run the code (maybe that would be the hardest part of
> the hack), and check if it worked correctly before (it should not); then
> test is simple replacement of value would fix it.

@Mike: I agree with you. The assignee have to understand and test the changes before submitting them.

I think this procedure would be good:

1. Understand what does this line of code does (or it was meant to do).
   + Wiki can help
2. Make sure this line of code works correctly.
   + Test it live with LibreOffice
3. Change it to something like blank to see if the functionality fails.
   + Change, build and test
4. Put the new code in place and make sure the functionality works again.
   + Change, build and test

@Shivam: If you have 2 line to change, change and test both of them. See what is appropriate for each of these lines.
Comment 7 Hossein 2021-12-12 16:24:48 UTC
@Shivam: Please work on 5401 (.uno:HelpIndex ) and 5404 (.uno:HelpTip ), as they are still available.

5400 (.uno:HelpOnHelp) and 5410 (.uno:HelpMenu) are removed here:
https://wiki.documentfoundation.org/index.php?title=Development/DispatchCommands&diff=236500&oldid=177137

Maybe we can take care of 5400 and 5410 later.

You can run UNO commands easily using a Python UI test:

https://wiki.documentfoundation.org/Development/UITests

This is an example test:

#!/usr/bin/python
from libreoffice.uno.propertyvalue import mkPropertyValues
from uitest.framework import UITestCase
from uitest.uihelper.common import get_state_as_dict
import time

class Test(UITestCase):

    def testUNO(self):
            time.sleep(2)
            print(self.xUITest.executeCommand(".uno:Quit"))
Comment 8 Shivam Jha 2021-12-12 16:27:47 UTC
Thanks that is very helpful
Comment 9 Mike Kaganski 2021-12-27 14:53:32 UTC
FTR: one special case of using slots is special "factory URL" syntax, like

  private:factory/swriter?slot=21053

see SfxFrameLoader_Impl::load. One place where it's used is in createSystrayMenu (sfx2/source/appl/shutdowniconw32.cxx), using IMPRESS_WIZARD_URL (private:factory/simpress?slot=6686).

I don't know what would be the optimal fix in this case, but possibly allowing to take "?.uno:Foo" instead of "?slot=nnn" would work, and impl_findSlotParam could convert the .uno to respective slot dynamically (e.g., using SfxGetpApp()->GetInterface()->GetSlot(sUnoURL)), to not change other code.

Caolan: do you think it's reasonable to add such "UNO slot parameter" to recognized syntaxes in impl_findSlotParam?
Comment 10 Hossein 2021-12-30 11:12:25 UTC
This is multi-hacker, so please just work on it, and don't assign it to yourself.
Comment 11 Caolán McNamara 2022-01-04 12:48:22 UTC
(In reply to Mike Kaganski from comment #9)
> Caolan: do you think it's reasonable to add such "UNO slot parameter" to
> recognized syntaxes in impl_findSlotParam?

I never really looked into it, but FWIW I see currently we have one
private:factory/sdatabase?Interactive
example and a
private:factory/swriter/GlobalDocument
variant along with, as far as I can see, only these other cases
private:factory/simpress?slot=6686
private:factory/swriter?slot=21051
private:factory/swriter?slot=21052
private:factory/swriter?slot=21053
where the impress one is the old "start with wizard" case (I think) which we removed (or made non-default at one point). Though ironically we now have a new "pick template" dialog which is shown by default. And I think the writer ones are the "business card", "label", "xml form?") wizards or something like that.

Maybe for those 4 cases we should follow the sdatabase case and just assign 4 "names" to these rather than replace it with an open-ended ?.uno:Command but I don't have any firm opinion there
Comment 12 Hossein 2022-06-16 13:44:10 UTC
Re-evaluating the EasyHack in 2022

This enhancement to the code is still relevant. Using dispatch command instead of numerical ID for the UNO commands can be done in many places found by the above grep command.
Comment 13 Commit Notification 2023-03-23 10:37:36 UTC
Bayram Çiçek committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/71311f88f7d83d8669576a98d300780d3d8bd02a

tdf#146150: Use dispatch command in framectr.cxx

It will be available in 7.6.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 14 Commit Notification 2023-09-25 11:04:33 UTC
apurvapriyadarshi committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/31ca96ff3075343c8d0c334fc77a9d0969986d77

tdf#146150 Use dispatch cmd for the corresponding SID

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