Bug 106732 - Autocaption shows Other OLE Objects instead of Spreadsheet, Draw, etc.
Summary: Autocaption shows Other OLE Objects instead of Spreadsheet, Draw, etc.
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.0.0.alpha0+
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.4.0 target:5.3.3 target:5.2.7
Keywords: regression
Depends on:
Blocks: AutoCaption
  Show dependency treegraph
 
Reported: 2017-03-23 22:29 UTC by Julien Nabet
Modified: 2017-07-04 20:08 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot (108.44 KB, image/png)
2017-03-24 10:21 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Nabet 2017-03-23 22:29:12 UTC
Description:
On pc Debian x86-64 with master sources updated today + enable-dbgutil + gtk3, I don't have SpreadSheet, Draw, etc in Autocaption


Steps to Reproduce:
1. Open Writer
2. Tools/Options
3. Select LibreOffice Writer
4. Select AutoCaption

Actual Results:  
Here's the list:
LibreOffice Writer Table
LibreOffice Writer Frame
LibreOffice Writer Image
Other OLE Objects
Other OLE Objects
Other OLE Objects
Other OLE Objects
Other OLE Objects

Expected Results:
Here's the list:
LibreOffice Writer Table
LibreOffice Writer Frame
LibreOffice Writer Image
LibreOffice Spreadsheet
LibreOffice Drawing
LibreOffice Formula
LibreOffice Chart
LibreOffice Presentation


Reproducible: Always

User Profile Reset: Yes

Additional Info:
In sw/source/ui/config/optload.cxx, in SwCaptionOptPage::Reset, I noticed that behaviour is ok if I first create a variable corresponding to SvGlobalName(SO3_OUT_CLASSID) then compare rOleId with it


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Comment 1 Julien Nabet 2017-03-23 22:30:17 UTC
I don't reproduce this with LO Debian package 5.2.5.1
=> Regression
Comment 2 Xisco Faulí 2017-03-24 10:21:17 UTC
Created attachment 132119 [details]
screenshot

I can't reproduce it in ( see screenshot )

Version: 5.4.0.0.alpha0+
Build ID: 1670cc25bc2771e87f7956a4b0dd634abaa4128b
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 3 V Stuart Foote 2017-03-24 11:26:48 UTC
Can not reproduce on today's TB42 build for Windows x86 on Windows 10 Pro 64-bit en-US, the full list of OLE types with just one "Other OLE Objects" check box selection is generated.

Version: 5.4.0.0.alpha0+
Build ID: 522e9c65faef684a22151ddf009a5a192838b522
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-03-24_00:32:45
Locale: en-US (en_US); Calc: CL
Comment 4 Julien Nabet 2017-03-25 07:01:39 UTC
On MacOs with master sources updated some days ago, I don't reproduce this.

Terrence: would you have a little time to give it a try?
Indeed, this one seems hard to reproduce. For example, perhaps it needs enable-dbgutil
Comment 5 Terrence Enger 2017-03-28 00:52:20 UTC
Thank you for thinking of me, Julien.

Working on debian-stretch, I do not see the bug in daily Linux dbgutil
bibisect repository versions 2017-02-02, 2017-02-03, 2017-03-22.  This
is true with the my user profile as I found it, in safe mode, and
naming a new profile directory on the command line.

However, I *do* see the bug in my local build of commit 9ba5eb22,
pulled 2017-02-02, configured
    CC=ccache /usr/bin/gcc
    CXX=ccache /usr/bin/g++
    --enable-option-checking=fatal
    --enable-dbgutil
    --enable-debug
    --without-system-postgresql
    --without-myspell-dicts
    --with-extra-buildid
    --without-doxygen
    --with-external-tar=/home/terry/lo_hacking/git/src
    --without-package-format

I have compared the generated user profiles, dbgutil bibisect repo
vs. localbuild.  The differences are benign except possibly
pack/autotext/mytexts.pack and pack/registrymodifications.pack, which
are binary files that I do not know how to read.

Setting SAL_USE_VCLPLUGIN={gen,gtk3} did not make any difference.

I am setting status NEW.
Comment 6 Commit Notification 2017-04-07 17:38:07 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=a7d008a8dfdc0a8b42061329b5e756b1b034abaf

Resolves: tdf#106732 the intent was surely to return a const ref

It will be available in 5.4.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 7 Caolán McNamara 2017-04-07 17:40:03 UTC
I think this will work now
Comment 8 Commit Notification 2017-04-07 20:17:05 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

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

Resolves: tdf#106732 the intent was surely to return a const ref

It will be available in 5.3.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 9 Commit Notification 2017-04-07 20:18:53 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1946bdabb8132a1989024f1bcd1d24806e1fae9e&h=libreoffice-5-2

Resolves: tdf#106732 the intent was surely to return a const ref

It will be available in 5.2.7.

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 10 Julien Nabet 2017-04-08 06:33:57 UTC
Thank you Caolán! I won't be able to check the fix for the moment to put the tracker to VERIFIED since I'm away for a week but I'll do it when I come back.
Comment 11 Terrence Enger 2017-04-08 22:33:31 UTC
My local build of commit 7e03a22b, pulled 2017-04-08, in the same
environment I described in comment 5, shows the desired results.

Caolán, if you know why my earlier local build showed the problem when
the daily dbgutil builds did not, that would increase the importance
of my current observation.
Comment 12 Caolán McNamara 2017-04-10 09:00:05 UTC
caolanm->Terrence: Do you still see this bug after my most recent change above ? Its appearance/disappearance in earlier versions may be somewhat random, i.e. use after free, in some cases the freed memory may be unchanged so it works anyway, while in other cases its reused so there's a bit of randomnesss to it
Comment 13 Terrence Enger 2017-04-10 12:53:33 UTC
Terrence->caolanm

No, no crash now.  I was just warning against paying too much attention to one no-crash result.

Thank you for the fix and your answer.
Comment 14 Julien Nabet 2017-04-16 06:31:53 UTC
I could check it's ok this morning, after having updated my local repo.

Thank you Caolán!