Bug 68291 - EDITING:[Regression] Page Break is Inserted Unintentionally
Summary: EDITING:[Regression] Page Break is Inserted Unintentionally
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: BSA target:4.2.0 target:4.1.3
Keywords: filter:rtf, regression
Depends on:
Blocks:
 
Reported: 2013-08-19 21:19 UTC by Harald Koester
Modified: 2015-12-17 12:22 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Koester 2013-08-19 21:19:48 UTC
Problem description: 
Under specific conditions a page break is inserted incorrectly into a text document.

Steps to reproduce:
[1] Create a new text document.
[2] Display non-printing characters.
[3] Insert 3 paragraphs with just one word.
[4] Insert another paragraph without text with “Enter”.
[5] Select first word with double-click.
[6] Copy to clipboard: Ctrl+C.
[7] Move cursor to last line.
[8] Paste clipboard as formatted text: Edit → Paste Special... → Formatted text [RTF] → OK: The word plus an end paragraph character is inserted. Expected: Only the word without the end paragraph character should be inserted.
[9] Select first word again with double-click.
[10] Copy to clipboard: Ctrl+C.
[11] Move cursor to last line.
[12] Insert clipboard with Ctrl+V: A page break and the word is inserted. Expected: only the word should be inserted.

Problem of step [8] exists in all versions from 3.5.0 to 4.1.0. Probably also before, I did not test it.

Problem of step [12] occurs first in version 4.0.0.
              
Operating System: Windows 7
Version: 4.1.0.4 release
Last worked in: 3.6.7.2 rc
Comment 1 Thomas van der Meulen [retired] 2013-08-22 14:39:21 UTC
Thank you for your bug report, I can reproduce this bug running LibreOffice.
Version: 4.1.1.2
Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903 on Mac osx 10.8.4.
Comment 2 Michael Stahl (allotropia) 2013-08-26 14:47:05 UTC
description sounds like it is likely caused by switching to the new RTF filter
Comment 3 Michael Stahl (allotropia) 2013-08-26 14:48:01 UTC
adjust version according to description
Comment 4 Miklos Vajna 2013-09-09 07:58:19 UTC
[8]: I just checked, even 3.4 behaves like this, so this is not new. Also, RTF documents are required to end with a new paragraph, so if you ask for "paste as RTF", that's sort of expected.

[12]: This is indeed an issue, this worked fine in 3.4.
Comment 5 Commit Notification 2013-09-09 08:52:06 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b226dcb50d6728b62f39c9fa2e016724324944e3

fdo#68291 RTF paste: don't set PageDescName during paste



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.
Comment 6 Miklos Vajna 2013-09-09 09:08:09 UTC
-4-1 review: https://gerrit.libreoffice.org/5883
Comment 7 Harald Koester 2013-09-09 09:45:27 UTC
(In reply to comment #4)
> [8]: I just checked, even 3.4 behaves like this, so this is not new. Also,
> RTF documents are required to end with a new paragraph, so if you ask for
> "paste as RTF", that's sort of expected.

I did some more tests according step [8]:
(1) Even if you copy one word from one sentence to another sentence with "paste as RTF" a paragraph end character is inserted, i.e. the sentence is split to 2 paragraphs.
(2) I did the same tests with WordPad, whose standard format is Rich text. With WordPad no paragraph end characters are inserted.

Of course you can argue that the LO behaviour is sort of expected, but to my opinion not a really coherent solution.
Comment 8 Commit Notification 2013-09-09 10:54:55 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2bf1604026fd4f69b4d727f931c9b33e2da30d8d&h=libreoffice-4-1

fdo#68291 RTF paste: don't set PageDescName during paste


It will be available in LibreOffice 4.1.3.

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.
Comment 9 Miklos Vajna 2013-09-10 07:22:57 UTC
Hi Harald,

Fair enough -- if this bothers you, please open a separate, non-regression bug (feel free to add me to CC), and I'll try to see what can I do. My primary point was that the newline part of the report is not a regression.

Thanks,

Miklos
Comment 10 Harald Koester 2013-10-09 12:57:20 UTC
Hi Miklos,

thanks for fixing. For problem of step [8] I wrote a new bug report (bug 70318). It does not really bother me. But perhaps it will be fixed some day by you or someone else.
Comment 11 Robinson Tryon (qubit) 2015-12-17 12:22:55 UTC
Migrating Whiteboard tags to Keywords: (filter:rtf)
Replace rtf_filter -> filter:rtf.
[NinjaEdit]