Description: Attachment 128299 [details] has problems with opening which is Bug 103533. This bug with it is specific to Linux and tested with LO 5.1 and 5.3 master. Steps to Reproduce: 1. Open attachment 128299 [details] in Linux 2. Go to sheet 82 3. Mark lower table 4. Delete rows (via right-click) Actual Results: It's just stuck and takes loong time. Expected Results: Rows deleted. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Console output (and it stays like this): warn:legacy.osl:5526:1:chart2/source/model/main/DataPoint.cxx:181: data point needs a parent property set to provide values correctly warn:legacy.osl:5526:1:svl/source/items/itempool.cxx:414: old secondary pool must be empty warn:legacy.tools:5526:1:svx/source/form/fmvwimp.cxx:444: FmXFormView::~FmXFormView: Window list not empty! warn:vcl.gtk:5526:1:vcl/unx/gtk/a11y/atklistener.cxx:597: Unknown event notification: 37 warn:vcl:5526:1:vcl/source/window/mouse.cxx:470: Window::ReleaseMouse(): window doesn't have the mouse capture
Created attachment 128325 [details] Test XLXS - 1 page Looks like it also happens with just 1 page extracted from Test XLXS. So, just try to delete rows 25-49.
Unconfirmed with v5.1.6.1 under windows 7 x64. Unconfirmed with v5.0.6.3 under mint 17.3 x64. Confirmed with v5.2.3.2 under ubuntu 16.04 x64. Seems linux only. Why not raise the importance to critical, as deleting rows is a basic fuction in calc ?!
(In reply to MM from comment #3) > Unconfirmed with v5.1.6.1 under windows 7 x64. If working in Windows, please also test Bug 103533. > Unconfirmed with v5.0.6.3 under mint 17.3 x64. > Confirmed with v5.2.3.2 under ubuntu 16.04 x64. When regression, added bibisectRequest. > Seems linux only. Why not raise the importance to critical, as deleting rows > is a basic fuction in calc ?! Because critical is when basic function is broken for all documents, and here it's just for a specific one: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Xisco, could you find some time to look at this one?
There are 2892 drawing layer objects on that sheet. Lines of effectively one dot in size, all in column 3, distributed over rows 6 (482), 8 (482), 30 (964) and 32 (964), all as hidden lines with no fill (actually could originate from clearpixels copied from HTML?). When deleting, 8682 registered listeners (mixed edit, object remove and a11y listeners) are (possibly multiple times) notified due to position and rectangle recalculations. Almost all time is spent in ScDrawLayer::SetPageSize() for all ScDrawLayer::RecalcPos() calls. Not sure if there can be done anything about that with this massive abuse, maybe some notifications can be suppressed and some "this dot does not change" special handling for such pathological case.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6a334757082be4915e7e731ce4c1b0bd4641050d Resolves: tdf#103543 disable mass broadcasts from drawing objects' changes 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.
Eike, thank you for this one. I got this file from colleagues who may indeed copy some data from HTML. I didn't understand from your explanation why this happens from 5.1.5? Is it a regression? Is there a need for "bibisectRequest" or we may remove that? When looking at 5.1.5 fixes I could only notice Bug 90285 and Bug 100764 as possibly related.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3d4aec8c32bf7b95657c40485f093c8e4a36b77c&h=libreoffice-5-3 Resolves: tdf#103543 disable mass broadcasts from drawing objects' changes It will be available in 5.3.0.1. 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.
(In reply to Timur from comment #8) > Eike, thank you for this one. > I got this file from colleagues who may indeed copy some data from HTML. You may want to fix the document for them in general, i.e. by removing all those drawings from the XML file, <xdr:twoCellAnchor> elements with hiddenLine and hiddenFill in ./xl/drawings/drawing1.xml of the zip package. > I didn't understand from your explanation why this happens from 5.1.5? Is > it a regression? Is there a need for "bibisectRequest" or we may remove > that? I'm removing. I even doubt it's a regression but I'm leaving that in. > When looking at 5.1.5 fixes I could only notice Bug 90285 and Bug 100764 as > possibly related. No, they are not. I think we're comparing apples and oranges here, or were all tests for this bug carried out on the same Linux distribution and version? Was the system's accessibility enabled for all? This may have significantly affected performance. On some newer Linux distributions a11y may be enabled even if no screen reader is active. Note this is independent of the setting in LibreOffice. However, this document is heavily broken, I'd not invest more time on it.
Eike, could you backport this to 5.2?
I was disinclined to cherry-pick this to 5-2 as it pulls out quite an axe to chop some wood.. I'd rather not have that in the penultimate (or even last) 5.2.z release.