Steps to replicate: 1. In Writer, insert a frame. 2. Set its width to AutoSize 3. Enter at least two paragraphs of text in the text frame 4. Open the Character Map in Windows and copy any character from it (this is the only 100% reliable way I know to force this bug.) 5. Paste the character(s) into the Writer document. Result: The text frame becomes 100% wide and cannot be made smaller anymore. Undo does not fix the problem, the document is now "corrupt". This is causing a headache for myself and others in my organization that need to use a lot of these text frames. With the Character Map this problem happens all the time. Otherwise it happens sporadically and I don't know why. If the characters are pasted without formatting then there is no problem. I am not sure if the bug only occurs during pasting or can be triggered by other things too. I narrowed the cause of the problem to one line in the settings.xml inside the .odt file. The line sets FrameAutowidthWithMorePara to true. If it is set to false there is no problem. (Also note that the problem is not noticeable if the frame only contains one paragraph.) What on earth is this FrameAutowidthWithMorePara setting? Why does it exist and what causes it to flip sometimes when pasting text? And why can't it be unflipped? Tested in 7.1.4 and 7.3.1.3, but I believe it is an old bug.
I can't confirm it with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: e8c95b796626cb9db163f5d563fa67f38a5e92b0 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Character map = Special Character Dialog? Does ist also happen with Help -> Restart in Safemode? => NEEDINFO
Dear lomacar, 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
Yes it happens in Safe Mode in 7.4.1. Did you have two paragraphs in the text frame?
(In reply to lomacar from comment #3) > Yes it happens in Safe Mode in 7.4.1. > > Did you have two paragraphs in the text frame? Yes, but is "character map" the same as "Special Character Dialog"? Perhaps you can check, if it is the same as bug 85762
I have tested this using LibreOffice 7.4.1.2 on both Ubuntu 22.04 and Windows 10 Home, and I don't have this error. 1. When you say, "copy any character from" Character Map, do you mean literally any character, even a letter? I tried a bunch of different characters, and none of them caused a problem. 2. Does it matter where you add the character? I tried in the middle of both the first and second paragraphs, and at the end. 3. Does it matter how long the paragraphs are? I used the two paragraphs from your report beginning "This is causing a headache …" and ending "… why can't it be unflipped?" 4. Which version of Windows are you using? 5. Does this happen in a brand new Writer document? If so, I wonder if the setting that you are referring to is in your template? Try opening a new document using a different template, perhaps one of those that come by default with LibreOffice.
(In reply to Dieter from comment #4) > (In reply to lomacar from comment #3) > > Yes it happens in Safe Mode in 7.4.1. > > > > Did you have two paragraphs in the text frame? > > Yes, but is "character map" the same as "Special Character Dialog"? > > Perhaps you can check, if it is the same as bug 85762 Character Map means the Windows Character Map, not the Special Character Dialog. You will not be able to produce the bug using anything internal to LO, I think. This bug appears unrelated to 85762.
(In reply to Paddy Landau from comment #5) > I have tested this using LibreOffice 7.4.1.2 on both Ubuntu 22.04 and > Windows 10 Home, and I don't have this error. > > 1. When you say, "copy any character from" Character Map, do you mean > literally any character, even a letter? I tried a bunch of different > characters, and none of them caused a problem. > > 2. Does it matter where you add the character? I tried in the middle of both > the first and second paragraphs, and at the end. > > 3. Does it matter how long the paragraphs are? I used the two paragraphs > from your report beginning "This is causing a headache …" and ending "… why > can't it be unflipped?" > > 4. Which version of Windows are you using? > > 5. Does this happen in a brand new Writer document? If so, I wonder if the > setting that you are referring to is in your template? Try opening a new > document using a different template, perhaps one of those that come by > default with LibreOffice. 1. Yes, any character. 2. It does not matter where you paste the text, inside or outside the frame. 3. The paragraphs can be empty or have any amount of text. 4. I'm using Windows 10. The bug happens for many people on different computers, but I believe they are all Windows based. It would be good to test on a Mac. 5. Yes, it happens in a new blank Writer document.
I have found another reliable way to produce the bug: copying and pasting anything from MS Word. Pasting unformatted text avoids the issue, so that is a possible workaround, but even when I tell people to just past unformatted text they are still running into the issue somehow. I just tested on another Windows 10 machine I own, with LO 7.0.0.3 and curiously it does not happen at all on there. Regardless, can't FrameAutowidthWithMorePara be completely removed from LO? What purpose does it serve? I can't find any information online. You have to admit that it is buggy behaviour when that attribute is turned on in a document and then pressing undo doesn't turn it off.
Steps: 1. In Writer, insert a frame and set its width to AutoSize 2. Enter at least two paragraphs of text in the text frame 3. Open any document in MS Word and copy some characters 4. Paste the character(s) into the Writer document. Actual result: Width changes to 100% of text area although width is still AutoSize. Expected result: Width should be width of the text. More curious 5. Insert a new frame with AutoSize 6. Place cursor inside frame and press enter => Width changes to 100% of text area although width is still AutoSize. => NEW
I have confirmed it on a Mac, OS X 11.6.7 with LO 7.3.6.2. I couldn't trigger it at first but when I did it revealed some more details. First off, macOS doesn't have a Character Map it has a Character Viewer, and merely copying and pasting from there did not trigger the problem. Also, when doing a plain copy and paste from Word to Writer, it did something crazy. I didn't look too close but it looked like it converted the text to an image or something before pasting it in. So that didn't trigger the bug either. BUT, then I noticed that the Character Viewer shows the selected character in a variety of fonts. And when I dragged a different font version of the character into LibreOffice then the bug was triggered! So clearly something to do with bringing formatted text into Writer can cause the bug, but maybe other things too.
This is the same issue with bug 151728. I have posted some useful info on recovering a document in that bug on a comment there. Pasting text from such applications (including even LO's formula code editor!) will switch LO to a broken compatibility mode. I don't know TDF's policy on marking duplicates but it's pretty certain that either bug must be marked as a duplicate.
I can't wait for this to be fixed, but for now I came up with a simple macro to fix this problem. Sub FixFrameBug dim oSettings oSettings=ThisComponent.createInstance("com.sun.star.text.DocumentSettings") oSettings.FrameAutowidthWithMorePara = false End Sub You have to save the document after running the macro to see the fix.
I'm following the steps and I can't reproduce the bug anymore. Like bug 151728, this one seems to have been fixed in 7.6 too -- thanks to whoever fixed bug 151974 !
I've tested again and the bug is fixed in 7.6 as I had reported last month. Related fixes in bug 151728 and bug 151974.
*** This bug has been marked as a duplicate of bug 151728 ***
*** This bug has been marked as a duplicate of bug 151974 ***