Bug 113615 - Basic command thiscomponent.currentselection(0).name returns wrong name of grouped Draw objects when GTK3 backend is used
Summary: Basic command thiscomponent.currentselection(0).name returns wrong name of gr...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
4.4 all versions
Hardware: All Linux (All)
: medium minor
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.0.0 target:5.4.4
Keywords:
Depends on:
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2017-11-02 23:18 UTC by Kai Struck
Modified: 2018-01-04 15:24 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Names_of_grouped_Draw_objects1.odt (17.37 KB, application/vnd.oasis.opendocument.text)
2017-11-02 23:19 UTC, Kai Struck
Details
Names_of_grouped_Draw_objects2.odt (11.53 KB, application/vnd.oasis.opendocument.text)
2017-11-02 23:20 UTC, Kai Struck
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kai Struck 2017-11-02 23:18:04 UTC
Description:
the BASIC command thiscomponent.currentselection(0).name returns the wrong name of grouped Draw Objects.
In Writer: If multiple Draw objects are grouped and this grouped object is given a name (e.g. "linegroup") the above command should return this grouped object name but it returns the name of one of the elements instead e.g "line1".
This error occurs in all tested LibreOffice-Versions (4 and 5er)and OpenOffice4 on most Linux systems like Linux Mint, Ubuntu. Both 64bit and 32bit versions. It works correctly on Lubuntu, Windows,OSX. 

Steps to Reproduce:
1. create 2 draw lines and give each a name. eg."line1" and "line2"
2. group the 2 lines
3. give the grouped object a name e.g. "linegroup"
4. select the object and run the basic program:
sub showname
msgbox thiscomponent.currentselection(0).name
end sub

It should show the name of the grouped object: "linegroup"
5. insert and delete texts. Save, try again.
At some point the error will occur and it will show the name of one of the elements e.g. "line2" instead of the grouped object ("linegroup")

Because it may not appear immediately try it with the attached files:
File1: Names_of_grouped_Draw_objects1.odt
At first it works, after deleting some text the error will occur.
File2: Names_of_grouped_Draw_objects2.odt
Here the error always occurs

Actual Results:  
At some point the error will occur and it will show the name of one of the elements e.g. "line2" instead of the grouped object ("linegroup")

Expected Results:
It always should show the name of the grouped object ("linegroup")


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:56.0) Gecko/20100101 Firefox/56.0
Comment 1 Kai Struck 2017-11-02 23:19:23 UTC
Created attachment 137487 [details]
Names_of_grouped_Draw_objects1.odt
Comment 2 Kai Struck 2017-11-02 23:20:45 UTC
Created attachment 137488 [details]
Names_of_grouped_Draw_objects2.odt
Comment 3 Buovjaga 2017-11-11 16:49:27 UTC
(In reply to Kai Struck from comment #2)
> Created attachment 137488 [details]
> Names_of_grouped_Draw_objects2.odt

I get the wrong result, if I use the GTK3 VCL plugin.
With all other plugins the result is correct.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha1+
Build ID: 1aba1955f161cc112dab80b6b3e78ec7761616fc
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on November 10th 2017
Comment 4 Kai Struck 2017-11-11 18:53:11 UTC
Thank you for investigating.
And finding the bug related to GTK3 VCL plugin.
I will try to confirm that (when I found an easy way to change that)
This explains why it works on certain systems like Lubuntu,CentOS out of the box and doesn't on Ubuntu,Linux Mint etc.

The importance may sure be minor but sadly is the major reason why a huge part of my extension is broken on these systems:
https://extensions.libreoffice.org/extensions/chorddiagrams
Comment 5 Buovjaga 2017-11-12 16:11:36 UTC
(In reply to Kai Struck from comment #4)
> Thank you for investigating.
> And finding the bug related to GTK3 VCL plugin.
> I will try to confirm that (when I found an easy way to change that)
> This explains why it works on certain systems like Lubuntu,CentOS out of the
> box and doesn't on Ubuntu,Linux Mint etc.

Sorry for not mentioning: you can use different VCL plugins by launching from the command line

SAL_USE_VCLPLUGIN=gtk libreoffice
SAL_USE_VCLPLUGIN=gtk3 libreoffice
SAL_USE_VCLPLUGIN=kde4 libreoffice
SAL_USE_VCLPLUGIN=gen libreoffice

We use minor severity usually when there is a workaround (not using gtk3 plugin in this case).
Comment 6 Caolán McNamara 2017-11-14 16:55:07 UTC
I think this isn't gtk3 specific, but an underlying bug which is easier to run into with gtk3
Comment 7 Commit Notification 2017-11-15 09:03:55 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

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

Resolves: tdf#113615 wrong SwXShape from three possibilities returned

It will be available in 6.0.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 8 Caolán McNamara 2017-11-15 09:06:10 UTC
backport to 5-4 in gerrit
Comment 9 Kai Struck 2017-11-17 20:36:45 UTC
Bug seems to be corrected in todays 
master~2017-11-17_00.29.00_LibreOfficeDev_6.0.0.0.alpha1_Linux_x86-64_deb.tar.gz 
on Linux Mint.

Congratulations!
I tested it with ChordDiagrams Extension that now again allows editing existing Shapegroups. (Wasn't possible before due to bug)
(the chord diagrams themselves are not drawn correctly in 6alpha, but this may be because of alpha status(?))

Don't know the meaning of
"backport to 5-4 in gerrit"

Thought it may say the bug will also be corrected in LO5.4 but in 
libreoffice-5-4~2017-11-17_09.32.39_LibreOfficeDev_5.4.4.0.0_Linux_x86-64_deb.tar.gz
the bug is existent.
Comment 10 Buovjaga 2017-11-18 12:31:43 UTC
(In reply to Kai Struck from comment #9)
> (the chord diagrams themselves are not drawn correctly in 6alpha, but this
> may be because of alpha status(?))

You can report that as a new bug.

> Don't know the meaning of
> "backport to 5-4 in gerrit"

It means it is submitted to the review tool gerrit: https://gerrit.libreoffice.org/#/c/44730/ It has not been merged yet
Comment 11 Kai Struck 2017-11-19 21:29:29 UTC
Thank you very much for the informations!
The other bug of wrong vertical positions of inserted Draw Objects is filed:
https://bugs.documentfoundation.org/show_bug.cgi?id=113938
Comment 12 Commit Notification 2017-11-22 15:54:29 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

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

Resolves: tdf#113615 wrong SwXShape from three possibilities returned

It will be available in 5.4.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 13 Kai Struck 2017-11-24 21:04:18 UTC
Wonderful, thank you!
Bug seems to be corrected in
libreoffice-5-4~2017-11-23_08.51.06_LibreOfficeDev_5.4.4.0.0_Linux_x86-64_deb.tar.gz 
on Linux Mint.
Comment 14 Kai Struck 2017-12-30 13:50:27 UTC
I also wrote the same Bugreport for OO:
https://bz.apache.org/ooo/show_bug.cgi?id=127604

They are now asking for a License Agreement from the developer of this patch to be able to use it in OO.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=74030e2aebb68218d829724329744e6992d6543b
Comment 15 Caolán McNamara 2018-01-02 21:26:22 UTC
> They are now asking for a License Agreement from the developer of this patch
> to be able to use it in OO.
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=74030e2aebb68218d829724329744e6992d6543b

Red Hat's commits to libreoffice are provided solely under the typical LibreOffice license combination of LGPLv3+/MPL as per https://lists.freedesktop.org/archives/libreoffice/2012-April/031021.html
Comment 16 Kai Struck 2018-01-04 13:30:47 UTC
They say the license is incompatible with OpenOffice's license so that LO can use OO code but OO can't use LO code. I'm personally not firm into license languages so would it be a problem if a nice person would have an eye on your code and adapt it to OpenOffice? Hope you don't mind the question.
Comment 17 Buovjaga 2018-01-04 14:36:20 UTC
(In reply to Kai Struck from comment #16)
> I'm personally not firm into
> license languages so would it be a problem if a nice person would have an
> eye on your code and adapt it to OpenOffice?

If you look at comment 10 in the AOO report you will have your answer: "Is there any way to delete the comments containing links to LO web pages and comments about them?

Although I have not followed any of the links, I have no way of proving that and may be influenced by the comments about them. As a result, I do not feel comfortable working on this bug. If the risky comments were deleted, future developers who have not seen them may be able to fix it."
Comment 18 Kai Struck 2018-01-04 15:24:35 UTC
Yes I saw that. And as this situation sounds so ridiculous to me ( someone found a solution but we can't use it and we can't fix the problem because now we know the other solution) I just went here to ask about it here.
Ironically I created this situation. Unaware of this license problems I provided as much information I could which now turns out to be a hindrance.