Created attachment 40687 [details]
Platform: SLED 11 sp1 i586
build info: LibreOffice 18.104.22.168
1. Launch writer and choose View->Toolbars->Form Controls
2. Click 'More Controls' button in the panel to call out an extra control
3. Click the 'Table Control' in the panel and draw a table inside, you
don't have to link any data inside.
4. Exit the Design mode by clicking 'Design Mode On/Off' button on the
form control panel called out in the step 1
5. Single click inside the table body
- This is a regression against OO.o 3.2.1
- The crash does not happen in LibO 22.214.171.124 Novell build, so there are
probably some difference here.
Hi Noel, maybe it's related with the VBA patch we did in beta1?
I did not see a crash or any other problem with "LibreOffice 3.3.0Beta3 - WIN XP DE [OOO330m12 (build 126.96.36.199)]" Did I overlook a detail in the step by step instruction or is WIN not affected?
(In reply to comment #2)
> I did not see a crash or any other problem with "LibreOffice 3.3.0Beta3 - WIN
> XP DE [OOO330m12 (build 188.8.131.52)]" Did I overlook a detail in the step by step
> instruction or is WIN not affected?
Thanks for trying this Rainer. Ye...looks Windows build does not appear the problem.
using Ubuntu 10.10 (64bit Gnome 2.32) and OpenSUSE 11.3 (32bit Gnome 2.3) w/ LibO 3.3. Beta 3 can not reproduce a crash. I checked with totally empty table controls (no columns) and after adding a few columns, again with no actual data source set. Switching design mode on/off - clicking into the control, on headers, and re-arranged column headers with design mode off...no crash, no problem at all.
hmm nothing in that stack looks like anything to do with any vba related changes infact it does look like it might be something to do with accessibility ( or at least triggered by FmGridControl::GetAccessibleObjectDescription(svt::AccessibleBrowseBoxObjType, long) const () at #10 )
it would be worth I think getting a debug stack ( with line numbers ) that might shed some more light ( hopefully )
Thanks for all your confirmation and analysis ;)
Noel, just remember I enabled 'Assistive Technologies' for another bug review. Disable it, the problem has been gone. Thank you!
So we got a workaround here, and impact getting more narrow. I'll lower the priority and remove it from the blocker.
Created attachment 40724 [details]
crash stack with debug info
update crash stack with debug info.
confirmed by stacktrace.
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
@Yifan Jiang, Björn Michaelsen:
The stacktrace is very old. Still a problem?
on Fedora 64 bit not reproduced in LibO 3.3.4 and 3.5.0 beta 1
I don't reproduce this problem with 3.5 branch on pc Debian x86-64.
No error in console too.
Do you still reproduce it ?
Dear bug submitter!
Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.
To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.
At least on Fedora 17 with accessibility enabled via
gsettings set org.gnome.desktop.interface toolkit-accessibility true
this is reproducible with a recent libreoffice-3-5 (towards LO 3.5.7) build: Load the 807450.odb attached as <https://bugzilla.redhat.com/attachment.cgi?id=573425> to <https://bugzilla.redhat.com/show_bug.cgi?id=807450> "[abrt] [a11y][reproducible] comphelper::OPropertySetAggregationHelper::getFastPropertyValue," open Form1, click e.g. into the square at the top-left of the table (i.e., the empty space to the left of the "Field1" header and above the columns).
However, it is no longer reproducible with neither a recent libreoffice-3-6 (towards LO 3.6.3) nor a recent master (towards LO 3.7) build. Call stacks leading up to accessibility::AccessibleBrowseBoxBase::AccessibleBrowseBoxBase -> FmGridControl::GetAccessibleObjectDescription have changed substantially there, and there are no more such calls with _eObjType=BBTYPE_BROWSEBOX that take the code path that leads to the UnknownPropertyException.
So it looks like this issue got fixed somewhere along the way from LO 3.5 to 3.6, but it is unclear to me which specific commit addressed it.