Bug 68607 - FILEOPEN: 8 page word document only displays page one
Summary: FILEOPEN: 8 page word document only displays page one
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: highest critical
Assignee: Miklos Vajna
Whiteboard: BSA target:4.2.0 target:4.1.3
Keywords: bibisected, regression
: 68692 (view as bug list)
Depends on:
Blocks: mab4.0
  Show dependency treegraph
Reported: 2013-08-27 13:14 UTC by Kevin
Modified: 2015-12-17 07:29 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

Offending document docx format (35.27 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-08-27 13:14 UTC, Kevin

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin 2013-08-27 13:14:24 UTC
Created attachment 84711 [details]
Offending document docx format

Problem description: 

Steps to reproduce:
1. Open the document
2. ....
3. ....

Current behavior: Shows one page only

Expected behavior: Show first of eight pages

Operating System: Windows 7
Version: release
Comment 1 Thomas van der Meulen [retired] 2013-08-27 14:34:09 UTC
Thank you for your bug report, I can reproduce this bug running LibreOffice.
Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903 on Mac osx 10.8.4. 

this is a regression from 3.6.7 since 4.0.x
Comment 2 V Stuart Foote 2013-08-27 14:53:05 UTC
Also an issue on Windows 7 sp1, 64bit
Build ID: 2d95a1bfd6e0adff791d9e381f0ec37470312522

Document consists of a single formatted Table that spans 8 pages (US Letter, with 1/2" margins).

In LibreOfficeDev master, document opens with a single table, but only two pages.  However, the entire table is present, and can be selected/pasted into a new LODev Writer document. The paste action generates all 8 pages in the new document and the table is fully intact from the original.

Document opens correctly formatted in Apache OpenOffice 4.0, and MS Office 2013
Comment 3 V Stuart Foote 2013-08-27 15:31:25 UTC
Confirm the regression
Version (Build ID: e183d5b)
in admin install on Windows 7 sp1 64bit.

Document opens correctly with the table spanning 8 viewable pages.
Comment 4 Michael Meeks 2013-08-27 15:38:07 UTC
If it's not inherited from our friends, then a bibisect might help find this.
Comment 5 V Stuart Foote 2013-08-27 16:14:10 UTC
LODev Version
(Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)

It came in as 8 pages, but the first 3 1/2 pages of table are blank. Table starts to display starting halfway down 4th page, pages 5 - 8 are correct.

So there was DOC/DOCX filter work being done during the 3.7 master phase. I'll see if I can find where/when the import filter drops the additional pages between 4.0.0 and

Always a joy...  meanwhile if someone with keys to the bibsects wants to try, they may get there first :)
Comment 6 Terrence Enger 2013-08-27 17:01:50 UTC
As I try to bibisect this regression, I see two different bad

The temporally first "bad" behaviour here is different from the
original report: Writer is aware that the document has nine pages, but
the first three and a bit pages are blank.  Display of text starts
part way down a line of text.  So, on the assumption that displaying
text of page 1 is "good" and displaying a blank page 1/9 is "bad",
bibisect tells me ...

    7b32edd2389319e0d394368c4109201528c41f7e is the first bad commit
    commit 7b32edd2389319e0d394368c4109201528c41f7e
    Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
    Date:   Tue Dec 11 02:50:26 2012 +0000
        commit 44b96a2fce52b6e3e683dc917fab219cf75001db
        Author:     Peter Foley <pefoley2@verizon.net>
        AuthorDate: Fri Nov 9 08:25:42 2012 -0500
        Commit:     Peter Foley <pefoley2@verizon.net>
        CommitDate: Fri Nov 9 08:25:55 2012 -0500
            fix lcms2 for mac
            Change-Id: If2477b9a391d75672a349ba240ceb61e0b06611a
    :100644 100644 6b13afd13f023cedac65a896318de4aa55dead27 6d85145f7ba0ead31c84e60a4f7ea59af07f4e83 M	autogen.log
    :100644 100644 0063e52dfa489f0913856b4d390a6dbaf3bf7c2b 4b626e19ae2cab663f8d71d383fe61cbf4d954fd M	ccache.log
    :100644 100644 92384a56b82df79bfe49d9b5829f20262b45cb48 e0429ebae3b3157170625d15b9f2e3a2dfe2a199 M	commitmsg
    :100644 100644 60a70480d7fe01f507e8df9a52a826399be70704 c263d2d4d032933f70146ad485a22b6660569a9e M	dev-install.log
    :100644 100644 7e7a596557e3553eb7c28ffa30dea1f0540e9ed5 cd8e792a15abc6fcbe35a181c280e27d5f384ba5 M	make.log
    :040000 040000 cbe3c5d02cb655be461366d3d0facb94bf5c6043 6e626fa3ce8a5f98caeab77c01ce9ab6766dcbae M	opt

and the output from `git bisect log` is

    # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4
    # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
    git bisect start 'latest' 'oldest'
    # good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c
    git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9
    # good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda
    git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a
    # good: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902
    git bisect good 114fd3b76bcba890e6d702d00cef910f1493c262
    # bad: [47498a36f7af8f54e6e3dda89cd4708802a409e6] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7
    git bisect bad 47498a36f7af8f54e6e3dda89cd4708802a409e6
    # good: [f4e2d84db194943180f3e7ed4adce5f8e377d9bc] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10
    git bisect good f4e2d84db194943180f3e7ed4adce5f8e377d9bc
    # good: [fb4214f9d134b556582a4a5280e5458de5f8eebd] source-hash-683758efb22d08a4cf211a6d985148f513da2a90
    git bisect good fb4214f9d134b556582a4a5280e5458de5f8eebd
    # bad: [7b32edd2389319e0d394368c4109201528c41f7e] source-hash-44b96a2fce52b6e3e683dc917fab219cf75001db
    git bisect bad 7b32edd2389319e0d394368c4109201528c41f7e
    # good: [6095212a5bd192017c6a20ee10de26a163372e8c] source-hash-a599f5b4b51848e3b397d471c9d12b373caadcef
    git bisect good 6095212a5bd192017c6a20ee10de26a163372e8c

On the assumption that opening the document with nine pages even if
the first 3 pages are blank is "good" and that opening the document
with 1 page whether blank or showing text is "bad", bisect tells me

    5bd1638c8d760b3a646054cfa8abf69e785ddd67 is the first bad commit
    commit 5bd1638c8d760b3a646054cfa8abf69e785ddd67
    Author: Jean-Baptiste Lallement <jean-baptiste.lallement@canonical.com>
    Date:   Tue Mar 12 16:49:53 2013 +0000

        commit 2d907dcca7edde8cd02446cf7322556095ba447f
        Author:     Tor Lillqvist <tml@iki.fi>
        AuthorDate: Wed Feb 20 15:26:00 2013 +0200
        Commit:     Tor Lillqvist <tml@iki.fi>
        CommitDate: Wed Feb 20 16:43:21 2013 +0200
            Change-Id: I9ecf4f57770151c1e4976c57d1f93982f35ac0fb

    :100644 100644 086733e5ccf68a2f407cf266d66741a7e95f7a13 75e2e82f87cb65723f484b40c6d2b9857c5eebda M	autogen.log
    :100644 100644 0478bb064fc1a1d3b34f9ba8567e8f2254c541b3 376d532b2d3dd80b5590eb59a40c7541c5920674 M	ccache.log
    :100644 100644 93177c199c9945fab789d19dcb2d066462490820 1b4e76290f0cafbcaf17728aa9b9a86220f1bb5d M	commitmsg
    :100644 100644 2fbfe6487af073e1532ee9f2bbc93df414b4abd8 125391857546dec8cf5f7f907b4f9db2906daa99 M	dev-install.log
    :100644 100644 d5d9e6274bf48f525142067fee62ac652f807f2f 35ec0047fe17b3b790fe514ac5753b3f557c1b9a M	make.log
    :040000 040000 be362fc2c7b5fdd95db2287be7e5b608c295f428 c070995233ff32acaa5a362c5611e3472d103a65 M	opt

and `git bisect log` says ...

    # bad: [4118d739dbd71e16057ea926ef3ef696025d3b67] source-hash-5bd6a5110bb812f82a81e73422a7b14851f84441
    # good: [3e7462bd65e692bf0592d5b080b7716341b62a47] source-hash-1eddfce9894fd05315173744f495619189093dc7
    git bisect start 'latest' 'oldest'
    # bad: [086c82fbd0a50dbf5dd28e8bcc7a6d702cea124e] source-hash-c74f2edfce221960fe546e88f2b3222d69d53598
    git bisect bad 086c82fbd0a50dbf5dd28e8bcc7a6d702cea124e
    # good: [3367a5f4f0d1768c35ed32ac1956abf5c3ab4e0d] source-hash-cc9cd7af3beb13eede23c6c60506c6e8c329e29d
    git bisect good 3367a5f4f0d1768c35ed32ac1956abf5c3ab4e0d
    # bad: [8609688fe6682504b3e6bc675e209db988d3acc1] source-hash-de69091d34d8102c0b56194d603ed9e66699d34c
    git bisect bad 8609688fe6682504b3e6bc675e209db988d3acc1
    # bad: [a0da7886ec5c1ecfc0b5a1e9a85a18459a764761] source-hash-a82f7b20539e60f1cf599afcceaf865bef297a66
    git bisect bad a0da7886ec5c1ecfc0b5a1e9a85a18459a764761
    # bad: [872ce1bed9806a36f0bec7eb1a1d09ceff38bdd6] source-hash-3d46b39491af97ba360fb92182501e6b399f4f56
    git bisect bad 872ce1bed9806a36f0bec7eb1a1d09ceff38bdd6
    # good: [a32a7357d8155228a87bce38c205c67b848af39c] source-hash-e0210c3ef0ed56a6b45934e2ecb5b42b99808199
    git bisect good a32a7357d8155228a87bce38c205c67b848af39c
    # good: [3e5c28677b95d304c3f61ff27555071b2188cb79] source-hash-ae1fbbfb690cb35eae7d56ae190d637d834697aa
    git bisect good 3e5c28677b95d304c3f61ff27555071b2188cb79
    # bad: [029bcd656063cbe8f4b84860e94a421f3556cea6] source-hash-7c351c32ea9b34f7b798c2487854753bb4693110
    git bisect bad 029bcd656063cbe8f4b84860e94a421f3556cea6
    # bad: [5bd1638c8d760b3a646054cfa8abf69e785ddd67] source-hash-2d907dcca7edde8cd02446cf7322556095ba447f
    git bisect bad 5bd1638c8d760b3a646054cfa8abf69e785ddd67
Comment 7 V Stuart Foote 2013-09-02 22:06:09 UTC
*** Bug 68692 has been marked as a duplicate of this bug. ***
Comment 8 V Stuart Foote 2013-09-03 01:21:00 UTC
OK in (2013-02-28) showing 8 pages and full table when opened.

Bad in (2013-03-14) showing as just 1 page, but full table intact--just not showing.

So somewhere prior to -- (2013-03-14)commit 1696ec904079360cf35a39f403aabc49699e8844
Comment 9 Miklos Vajna 2013-09-03 08:52:25 UTC
I just checked the bugdoc, this is the same situation as described here:

Comment 10 Miklos Vajna 2013-09-03 09:54:04 UTC
Erm, except that here surely no wrapping would be performed, while there that's not so clear. I'll do a port of 8fe8bd6c3b5b1a539b7370f8c457fa69c061d2de for the DOCX filter, that should help here.
Comment 11 Commit Notification 2013-09-03 10:22:30 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":


fdo#68607 bnc#816593 DomainMapperTableHandler: don't always start a frame

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:
Affected users are encouraged to test the fix and report feedback.
Comment 12 Miklos Vajna 2013-09-03 14:26:25 UTC
-4-1 review: https://gerrit.libreoffice.org/5788
Comment 13 Commit Notification 2013-09-06 11:42:26 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":


fdo#68607 bnc#816593 DomainMapperTableHandler: don't always start a frame

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:
Affected users are encouraged to test the fix and report feedback.
Comment 14 Michael Meeks 2013-09-06 16:28:41 UTC
Thanks Miklos - nice work :-)
Comment 15 Timur 2013-09-09 09:46:51 UTC
Will it also be in 4.0.x?
Comment 16 V Stuart Foote 2013-09-10 02:24:24 UTC
Confirmed working correctly on master...

Build ID: 5b74c6563cfc802b5330fb82500be9d6cd835fe2
TinderBox: Win-x86@39, Branch:master, Time: 2013-09-09_18:53:01

Will verify agains a 4.1.3 TB when available.

Thanks, Miklos!
Comment 17 Miklos Vajna 2013-09-10 07:57:51 UTC
Hi Timur,

Sorry, I don't think so. The fix had 5 dependent commits, I fear backporting to -4-0 would need even more dependency hunting, so ATM I don't plan to do so.

Comment 18 Robinson Tryon (qubit) 2015-12-17 07:29:54 UTC
Migrating Whiteboard tags to Keywords: (bibisected)