Bug Hunting Session
Bug 83300 - FILEOPEN: DOCX - Image anchored as 'As Character' positioned on wrong page
Summary: FILEOPEN: DOCX - Image anchored as 'As Character' positioned on wrong page
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.7.2 release
Hardware: All All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:5.1.0 target:5.0.4
Keywords: bibisected, bisected, regression
: 82029 (view as bug list)
Depends on:
Blocks: DOCX-Images
  Show dependency treegraph
 
Reported: 2014-08-31 16:22 UTC by Yousuf Philips (jay) (retired)
Modified: 2017-10-22 22:17 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot with red rectangles around the 3 wrong parts (266.86 KB, image/png)
2014-08-31 16:22 UTC, Yousuf Philips (jay) (retired)
Details
shrunk sample docx (240.26 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-12-31 20:42 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-08-31 16:22:39 UTC
Created attachment 105493 [details]
screenshot with red rectangles around the 3 wrong parts

Steps:
1) Open attachment 103815 [details]
2) Switch to Web Layout
3) 2 frames and microsoft logo that were on the last page in Print Layout will appear now on the first page

Tested on master 2014-08-30 on Linux. In 3.3 it is fine. In 3.5.7, the microsoft logo appeared on the first page. In 4.1.6, the frames are on the first page.
Comment 1 Joel Madero 2014-09-03 08:37:23 UTC
Confirmed:
Bodhi 2.x
LibreOffice 4.4 built a couple days ago

New
Normal - can prevent high quality work
Medium - default seems fine, despite it being a regression, "web layout" seems to be quite rare generally and so far we have a single test case.

Regression - from Jay's point that it works fine in 3.3, I started a bibisect and I saw that it was at least slightly better in 3.6

bibisectRequest
Comment 2 Matthew Francis 2014-12-10 07:27:25 UTC
Bibisect results from 43all:
Not sure what's going on with that logo (can't always see it), but the positioning of the frames regresses as below


a0f20bc04a32a7791ba765d2de2f44f1b74033d1 is the first bad commit
commit a0f20bc04a32a7791ba765d2de2f44f1b74033d1
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Thu Oct 17 08:46:34 2013 +0000

    source-hash-1de66ba440855050a794b3b2a8647c1b02c210b8
    
    commit 1de66ba440855050a794b3b2a8647c1b02c210b8
    Author:     Armin Le Grand <alg@apache.org>
    AuthorDate: Thu May 30 13:09:07 2013 +0000
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Thu May 30 16:49:21 2013 +0100
    
        Resolves: #i122410# extended Undo/Redo for text to broadcast
    
        (cherry picked from commit d2c3483aa1c4fcce2678f9602d4204c908b4f874)
    
        Conflicts:
        	svx/source/svdraw/svdundo.cxx
    
        Change-Id: If4e96f6c192d381324e12a3acea87f624ef194ea

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [a71a4447320f177181c9cff9f7c6fd93802cbd8e] source-hash-9afb6e1e38c362a768e8e981f7b03cf8bcaf22cf
git bisect start 'latest' 'last36onmaster'
# bad: [f2554751603ad8537257b3cf52d6171056c76eeb] source-hash-f42768fe0b60ecbbe9c68d775329bf28c0690131
git bisect bad f2554751603ad8537257b3cf52d6171056c76eeb
# good: [c826604de689fbabd8b1b8ea41396694e99a23d4] source-hash-32acb98b3fb6acb4712f7195cf5ea1bd69c9c6b4
git bisect good c826604de689fbabd8b1b8ea41396694e99a23d4
# good: [e818f97b99709bcedf56865e733647666cfae09c] source-hash-66e39940d763586060c4bcc8c3cd213495c40b79
git bisect good e818f97b99709bcedf56865e733647666cfae09c
# bad: [e128a0b9bd133d989b87354bd271ef25c642b7bc] source-hash-7be71336862204f0763fc2f8cf62a6f48f341114
git bisect bad e128a0b9bd133d989b87354bd271ef25c642b7bc
# bad: [69bf614869471f46413fe1d2af5976b2e6d85084] source-hash-76dea8b2db906156e77f78738a68f932a15afd4b
git bisect bad 69bf614869471f46413fe1d2af5976b2e6d85084
# bad: [83c4b38e3383fa59cb8c8fe440f8b9e48fcae2c6] source-hash-44404b7a6c7bb3b95d03094abb745f29a5154959
git bisect bad 83c4b38e3383fa59cb8c8fe440f8b9e48fcae2c6
# good: [6848bca2a871fce1f3f28a8471eab4e5888ac9c9] source-hash-b45876bf0f2eeafba0a4f9f8f30cd4279eb2aa3e
git bisect good 6848bca2a871fce1f3f28a8471eab4e5888ac9c9
# bad: [bb1ef709fce943598a8bcab0234b9a4ba1b2e69a] source-hash-c4cca49f49408bc4094bdfcf782de2f7cd16ce6a
git bisect bad bb1ef709fce943598a8bcab0234b9a4ba1b2e69a
# bad: [a0f20bc04a32a7791ba765d2de2f44f1b74033d1] source-hash-1de66ba440855050a794b3b2a8647c1b02c210b8
git bisect bad a0f20bc04a32a7791ba765d2de2f44f1b74033d1
# first bad commit: [a0f20bc04a32a7791ba765d2de2f44f1b74033d1] source-hash-1de66ba440855050a794b3b2a8647c1b02c210b
Comment 3 Matthew Francis 2014-12-31 16:28:46 UTC
Attempting to reproduce on a build from source in the bibisect region ends in a crash when selecting Web Layout mode, which is a little disappointing. Unfortunately attempting to minimise the file (using LO) doesn't give a working reproduction either. Nothing leaps out from the list of commits either

Out of ideas on this one for now...
Comment 4 Yousuf Philips (jay) (retired) 2014-12-31 20:42:48 UTC
Created attachment 111597 [details]
shrunk sample docx

Hey Matthew,

I've shrunk the file down to 5 pages and hope that will make it easier.
Comment 5 Matthew Francis 2015-01-01 03:25:06 UTC
The minimised file helped, I can see where the behaviour changed now. It looks like it was the below commit.

Adding Cc: to vmiklos@collabora.co.uk. Could you possibly take a look at this? Thanks

commit f2720b87093968670e3fb47d24d4952f1631a654
Author: Miklos Vajna <vmiklos@suse.cz>
Date:   Wed May 29 14:47:54 2013 +0200

    bnc#817956 VML import of mso-position-vertical-relative:margin
    
    Change-Id: I86464c44022ef8c8a8037d4228bb2a6409fc77af
Comment 6 Miklos Vajna 2015-11-13 21:35:39 UTC
The mentioned shapes are anchored to the top of the page, and in web view, you have a single page, that's how they are moved to the top. The reason it started to behave this way at the above commit is that previously we didn't import the anchor settings correctly. So technically this is not a regression, just a Word vs. Writer difference that became visible, now that an import filter correctness problem is fixed.

Making the Writer web layout behave like the Word one wrt. page text are anchoring is far from trivial... feel free to open a non-regression bug for it, if you want.

However, there is something easy to improve in the bugdoc: the second page has an as-char anchored image that is on the first page in Word, I'll take care of that.
Comment 7 Commit Notification 2015-11-16 19:44:03 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

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

tdf#83300 DOCX import: 'TOC Heading' should not be 'keep with next' by default

It will be available in 5.1.0.

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 8 Yousuf Philips (jay) (retired) 2015-11-18 13:41:52 UTC
(In reply to Miklos Vajna from comment #6)
> Making the Writer web layout behave like the Word one wrt. page text are
> anchoring is far from trivial... feel free to open a non-regression bug for
> it, if you want.

Reported as bug 95906.

> However, there is something easy to improve in the bugdoc: the second page
> has an as-char anchored image that is on the first page in Word, I'll take
> care of that.

Changed title to correspond to this fix.
Comment 9 Yousuf Philips (jay) (retired) 2015-11-18 13:47:38 UTC
*** Bug 82029 has been marked as a duplicate of this bug. ***
Comment 10 Commit Notification 2015-11-23 17:13:18 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0750162d3dbdd1bbd01ad01c383a26199e58419a&h=libreoffice-5-0

tdf#83300 DOCX import: 'TOC Heading' should not be 'keep with next' by default

It will be available in 5.0.4.

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 11 Robinson Tryon (qubit) 2015-12-17 08:34:20 UTC Comment hidden (obsolete)