Description: Layout freeze with specific document and an image anchored to character at the wrong spot As reported earlier.. 'to character' different from 'to character' shape. To shape anchoring is really error prone. To character handling for images is better.. but not failure proof.. Steps to Reproduce: 1. Open the attached file 2. Press and hold enter at the beginning.. at paragraph 6 it will freeze But how did you get the image there.. if I touch it won't stick anymore I inserted it there normally..but there is some preventing mechanism being.. so if you move the image.. you can't put it back in a 'broken' position.. or you have to try hard.. You can't drag it at the point.. but can be overruled Image -> properties -> Position (set to say 2 from top..) So 2 ways to create. 1. Insert image first and start editing 2. Be the (un)lucky one who can drag it into such a position 3. Force a certain position Image -> properties -> Position 4. Copy/paste/ inserting an image.. Actual Results: Freeze/hang Expected Results: To character for image is default these days Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: a35c18aeff3b1d8f270db7e094850fb8ba1ab84a CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 162125 [details] Example file
I'm hoping for an assert..
On pc Debian x86-64 with master sources updated today, I don't have an assertion but it freezes after some "Enter".
Can whole "anchor to character" by default change be postponed for a while.. so be reverted for 6.4.. there a quite a number of bug attached to it.. Layout loops.. freezes, insert wrong spot, empty pages, etc.. I reported quite a number of issues with anchoring already.. in the past month or so.. Yes, this could happen before.. but this change extends the scope quite a lot.. So being a bad choice.. especially for 6.4.5.. should be trustworthy, IMHO
There were 2 steps: - to-para -> as-char anchoring: the old state was suboptimal, it instantly lead to format loss when saving to Word formats, etc. (see the commit message for details) My motivation was to use something by default that roundtrips to Word formats, so as-char or to-char. We went with as-char as that's the Word default. - as-char -> to-char anchoring: this was done because users expect to be able to drag the just inserted image and while Word supports that, our UI does not, so to-char is an easy compromise: still no format loss but the UI allows drag out of the box. I guess changing defaults is annoying, so I would rather fix root causes than continue changing defaults. But of course, feel free to submit a change if you disagree.
(In reply to Miklos Vajna from comment #5) > I guess changing defaults is annoying, so I would rather fix root causes > than continue changing defaults. Changing defaults is annoying -> Not saying it isn't. Ideally it should be tested a little more (or looking at the bug tracker, before making a change.. simple changes like this tend to backfire I would rather fix root causes O yes, fixing the root cause surely sounds better, but (a) this is inherited, so no code pointers (b) the responsibility of no-one; and not sure of anybody will (or should) volunteer (c) layout code + anchoring being everywhere; so it probably will cause quite a number of regressions.. It's impossible to push changes into 6.4 and i'm not even sure if would make it into 7.0.. So 2 full releases with type of issue; with the potential of giving a bad impression.. I'm only attempting to act as an early warning system. And I'm hoping I'm overestimating the issue. Note: I won't push a revert commit, as I'm not knowing what I'm doing. However, i'm not seeing the revert as a blame-full act. As there are reason to do so - temporarily. Instead replacing an old issue for something new; with an even large scope. But, i'm a newbie.. For the pressure to solve things is right direction BTW. But prefer careful planning/testing instead of rushing something through. And following Heiko's poll people tend to change the anchor anyway.. But my two cents..
@Justin (In reply to Miklos Vajna from comment #5) > There were 2 steps: > > - to-para -> as-char anchoring: the old state was suboptimal, it instantly > lead to format loss when saving to Word formats, etc. (see the commit > message for details) > > My motivation was to use something by default that roundtrips to Word > formats, so as-char or to-char. We went with as-char as that's the Word > default. > > - as-char -> to-char anchoring: this was done because users expect to be > able to drag the just inserted image and while Word supports that, our UI > does not, so to-char is an easy compromise: still no format loss but the UI > allows drag out of the box. > > I guess changing defaults is annoying, so I would rather fix root causes > than continue changing defaults. But of course, feel free to submit a change > if you disagree.
(In reply to Miklos Vajna from comment #5) > I would rather fix root causes Unfortunately, I haven't seen anyone dedicating their time to fixing any of the root causes. So the theory of incremental improvement is very nice, but the reality doesn't follow, thus proving the theory to be false. And incremental improvements that ends up being a complete failure should be reverted and then newly fixed in master, not fixed in a released product. The massive print dialog in 6.3 was another prime example of that too.
(In reply to Miklos Vajna from comment #5) > But of course, feel free to submit a change if you disagree. It is much better for the author to acknowledge that LO isn't up to par yet for the desired change and do the revert himself. Once the identified issues have been resolved, it can be attempted again in an early cycle of the next master. This isn't "continue changing defaults". It is NOT changing the default at all. It is keeping LO broken in the way that people are used to, instead of broken in many new ways - which is very frustrating (comment 4).
Created attachment 174189 [details] Did I understand the problem correctly? Reproducible, but as I understand it a little later than it was written in the original problem. Did I understand the problem correctly? Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: b2130ad3fda841c68a0436fbddf29bcedede0af5 CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: ru-RU (ru_RU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-08-09_13:03:07 Calc: threaded Log: warn:sfx.dialog:21596:21596:sfx2/source/dialog/filtergrouping.cxx:357: already have an element for WordPerfect warn:sfx.dialog:21596:21596:sfx2/source/dialog/filtergrouping.cxx:357: already have an element for writerweb8_writer_template warn:sfx.dialog:21596:21596:sfx2/source/dialog/filtergrouping.cxx:357: already have an element for writerglobal8 warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/text/XMLTextFrameContext.cxx:1066: unknown attribute http://www.w3.org/1999/xlink xlink:type value=simple warn:xmloff:21596:21596:xmloff/source/text/XMLTextFrameContext.cxx:1066: unknown attribute http://www.w3.org/1999/xlink xlink:show value=embed warn:xmloff:21596:21596:xmloff/source/text/XMLTextFrameContext.cxx:1066: unknown attribute http://www.w3.org/1999/xlink xlink:actuate value=onLoad warn:sw:21596:21596:sw/source/core/graphic/grfatr.cxx:291: Put/QueryValue should be removed! warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:xmloff:21596:21596:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:1158: context should have a size warn:legacy.osl:21596:21596:sw/source/core/layout/flowfrm.cxx:2561: <SwFlowFrame::MoveBwd(..)> - layout loop control for layout action <Move Backward> applied! warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame? warn:legacy.osl:21596:21596:sw/source/core/layout/ftnfrm.cxx:1463: InsertFootnote: Master expected II
Dear Telesto, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Freezes after pressing Enter 7 times.. it doesn't freeze if you press and hold enter. So only when doing it slowly Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ca657b98e49eb2282775f7919827062a7a0b4bfe CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
[Automated Action] NeedInfo-To-Unconfirmed
A fascinating argument has developed around this theme but still, I think there's a lot of politics around this issue. If you want to buy some upscale jackets at discounted prices, Click on the link below. https://rleatherjackets.com/product/men-ribera-steak-house-red-jacket/
Telesto, any changes in LO 7.6? => NEEDINFO
Dear Telesto, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp
1. Open the attached file 2. Hit enter 7x 3. Look at the task manager. 100% CPU usage..