Bug 49930 - FORMATTING : Pressing "Enter" key changes paragraph style of just completed paragraph.
Summary: FORMATTING : Pressing "Enter" key changes paragraph style of just completed p...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-14 14:08 UTC by Dwight Scott Miller
Modified: 2015-03-11 05:49 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
sample document (797.82 KB, application/vnd.oasis.opendocument.text)
2012-05-14 14:08 UTC, Dwight Scott Miller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dwight Scott Miller 2012-05-14 14:08:34 UTC
Created attachment 61653 [details]
sample document

Press enter at the end of a paragraph with a Custom Style. Instead of getting a new paragraph with the same style, I get a new paragraph with the same style, but the prior paragraph changes to "First Line Indent" for some styles, "Text Body Indent" for others. Pressing Ctrl-Z returns the prior paragraph to the correct (custom) style.

I have verified that the style specifies itself as the "Next Style" and is linked with "None". I have verified that "AutoUpdate" is OFF.

I tried building a new style from scratch and the error still occurs, even in a new, empty document. The problem does *NOT* occur when using built-in styles, but occcurs for *ALL* custom styles.

Version is 3.5.3.2 Build ID is a long ugly string in the "Help, About" ending in e241b80 which I would paste here if it were copyable!
Comment 1 Christina Rossmanith 2012-09-18 07:29:50 UTC
Even worse here with Version 3.7.0.0.alpha0+ (Build ID: 784302d). Opening the attached document causes a crash:

warn:legacy.osl:2895:1:/home/cr/Software/LibO2/core/sw/source/core/layout/frmtool.cxx:2719: Descriptor without any format?!
warn:legacy.osl:2895:1:/home/cr/Software/LibO2/core/sw/source/core/layout/wsfrm.cxx:104: No frame format passed.

segmentation fault (core dumped)
Comment 2 Owen Genat (retired) 2013-04-30 01:56:46 UTC
I have had a look at the provided test document and apart from the fact that it is rather large, and thus not a simple test, the styles within appear to behave exactly as one might expect. Each recipe has four pieces of content with a related paragraph style (shown in round brackets) and a next paragraph style definition [shown in square brackets]: 

 1. heading (RecipeHead) [RecipeCmmnt]
 2. leading comment (RecipeCmmnt) [RecipeIngred]
 3. list of ingredients (RecipeIngred) [RecipeInst]
 4. method / instructions (RecipeInst) [RecipeInst]

Testing the document (using TDF LO v3.5.7.2 and v4.0.2.2 under Ubuntu 10.04 x86_64 by pressing ENTER at paragraph end at random locations throughout its length) did not produce any observed behaviour being at odds with the style definitions in use. There are however instances where the styles are used out of order or a modified variant of one of these paragraph styles is employed e.g.,

p.53 "Julie's Rum Cake" RecipeInst style is used for sub-heading content above list of ingredients.
p.89 "Sour Cream Pound Cake" RecipeInst style is used for sub-heading content above list of ingredients.
p.92 "Sourdough Starter - Not from Scratch" RecipeCmmnt style is used for sub-heading content above instructions, some of which are formatted with an unordered list attribute.

There could well be other examples, but this is illustrative. It is to be expected that in these situations pressing ENTER will not result in the desired style (that is, contextually).

I suggest this bug can be closed as NOTABUG.
Comment 3 QA Administrators 2015-03-04 02:23:04 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1.2 or later): https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

Thank you for your help!

-- The LibreOffice QA Team
This NEW Message was generated on: 2015-03-03
Comment 4 Jean-Baptiste Faure 2015-03-11 05:49:15 UTC
Not reproducible for me with LibreOffice 4.4.2.0.0+ built at home under Ubuntu 14.10 x86-64
Closing as WorksForMe.

Best regards. JBF