Bug 121391 - It should be possible to position an object on a different page than its anchor (see comment 10)
Summary: It should be possible to position an object on a different page than its anch...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 150484 (view as bug list)
Depends on:
Blocks: Anchor-and-Text-Wrap
  Show dependency treegraph
 
Reported: 2018-11-13 14:14 UTC by Aron Budea
Modified: 2023-03-17 12:29 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample ODT (31.73 KB, application/vnd.oasis.opendocument.text)
2018-11-13 14:14 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2018-11-13 14:14:50 UTC
Created attachment 146593 [details]
Sample ODT

Open the attached document with a long single paragraph, and a shape anchored to the paragraph.
Try to drag the shape to the next page.

=> A couple of things might happen:
- the chape can disappear completely,
- the shape might disappear, but the area and selection outline remains,
- the shape might fail to leave the first page (versions < 6.1).

While the sample is extreme as it contains a single paragraph, the behavior is the same with a paragraph spilling over to the next page.

Observed using versions 6.2.0.0.alpha1+ (397dd8a5f7694540f31f32759c2c915d63506ccd), 3.3.0 / Windows 7.
Comment 1 Telesto 2018-11-13 16:52:40 UTC
Sounds a lot like bug 120839
Comment 2 Aron Budea 2018-11-13 18:08:49 UTC
(In reply to Telesto from comment #1)
> Sounds a lot like bug 120839
There are similarities, perhaps the changed behavior is related to the same commit, but this never worked properly.
Comment 3 Chen yu an 2018-11-29 09:46:15 UTC
Bug confirmed.

Using the attached file.
On page 3 top bug confirmed.

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
Locale: zh-TW (zh_TW); UI-Language: en-US
Calc: threaded
Comment 4 Chen yu an 2018-11-29 09:49:46 UTC
(In reply to Chen yu an from comment #3)
> Bug confirmed.
> 
> Version: 6.3.0.0.alpha0+ (x64)
> Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
> CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
> TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
> Locale: zh-TW (zh_TW); UI-Language: en-US
> Calc: threaded
Comment 5 Durgapriyanka 2018-12-03 22:24:51 UTC
I can confirm that the bug is present in 

Version: 6.0.6.2
Build ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77
CPU threads: 2; OS: Windows 6.1; UI render: default; 
Locale: en-US (en_US); Calc: group
Comment 6 QA Administrators 2019-12-04 04:20:29 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2021-12-04 04:42:37 UTC Comment hidden (obsolete)
Comment 8 Aron Budea 2021-12-04 06:36:32 UTC
Still in LO Version: 7.4.0.0.alpha0+ (ba7db98cca3d8516697c94ef0d6af27db9e1655e) / Ubuntu.
Comment 9 Dieter 2022-09-05 10:18:13 UTC
*** Bug 150484 has been marked as a duplicate of this bug. ***
Comment 10 Dieter 2022-09-05 10:48:26 UTC
Help states clearly: "Objects can only be positioned on the page where their anchor is located." https://help.libreoffice.org/7.4/en-GB/text/swriter/guide/anchor_object.html?&DbPAR=writer&System=WIN

So actual behaviour is the expected one. So for me NOTABUG. Aron feel free to reopen it as enhancement request or file a new report as enhancement, if you think, we should change current behaviour.

Workaround:
Change anchor to page.
Comment 11 Aron Budea 2022-09-05 15:18:19 UTC
(In reply to Dieter from comment #10)
> Help states clearly: "Objects can only be positioned on the page where their
> anchor is located."
> https://help.libreoffice.org/7.4/en-GB/text/swriter/guide/anchor_object.
> html?&DbPAR=writer&System=WIN
> 
> So actual behaviour is the expected one. So for me NOTABUG. Aron feel free
> to reopen it as enhancement request or file a new report as enhancement, if
> you think, we should change current behaviour.
Thanks for the comment Dieter! For the record, that addition to the help was made fairly recently in 7.4 for bug 149353, and it rather seems to me a comment to inform users of this limitation than the actual expected behavior (at least, concerning the steps in this report).

I'd maintain that this is a bug from the user's perspective, but I can also understand this is currently a limitation, so switching this from bug to enhancement is fine.
Comment 12 Dieter 2022-09-05 15:33:27 UTC
(In reply to Aron Budea from comment #11)
> so switching this from bug to
> enhancement is fine.

I've also changed bug summary to make enhancement request more visible.

Regina, are there are any limitations from odf-specification?
cc: Regina Henschel
Comment 13 Regina Henschel 2022-09-05 16:32:29 UTC
The ODF specification does not mention such case. From the existing text I see nothing, that would limit it.

But from a practical point of view, I see big problems. The layout algorithm is already very fragile, and Word has the same behavior. So changes are extremely vulnerable to regressions.