Created attachment 66037 [details] Test document (sorry, I cannot provide a shorter version at the moment) Problem description: A 13-page document shows "Page 1/13" as the document loads, but then reduces to "Page 1/4" after being fully loaded. To reproduce: Open attached document. Lower left corner of screen initially reads "Page 1/13" Wait a moment or two Lower left corner of screen reads "Page 1/4" Current behavior: Document is truncated Expected behavior: Document should fully load Platform (if different from the browser): Browser: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0.1
Thank you very much for your bug report! > Problem description: A 13-page document shows "Page 1/13" as the document > loads, but then reduces to "Page 1/4" after being fully loaded. This is REPRODUCIBLE with LibreOffice 3.6.1.2 (Build ID: e29a214), German langpack installed, on MacOS X 10.6.8 (Intel). But IMHO the main problem is not that pages 5 to 13 (or even 14, on my machine) disappear after opening the document; the main problem is that the complete contents of these pages are missing. And *this* -- all document contents are missing after page 4, point 11a., last line: "Designing with Web Standards (3rd Edition), Jeffrey Zeldman and Ethan" -- is already REPRODUCIBLE with LibreOffice 3.5.6.2 on the same machine: it shows 14 pages, of course but pages 5 to 14 are blank (and you even can’t reach them with the cursor!), so all contents after the line cited above is missing. Note: as soon as you click into the last visible line cited above, 3.5.6.2 hides the following pages, too, so only the 4 valid pages are left. -> Adapted Version and Summary fields. LibreOffice 3.4.6 loads the complete text of the document, or at least more of it, so there is probably an regression involved. -> Added keyword "regression".
@Rainer: Can you reproduce this issue on Windows? What do you think: is this a LibO 3.5 MAB candidate? I am not sure. On the one hand, I would say "yes, definitely a MAB" -- missing most of the contents of a file is not good :-( On the other hand, the report is only about a particular document. But it seems probable that this bug will also affect more documents ... Thank you! [I have checked that this document was really created with MSO2007 by looking at the XML data.]
6d6e5252d2c81fa930cb89f3eaf0efadf09cb87f is the first bad commit commit 6d6e5252d2c81fa930cb89f3eaf0efadf09cb87f Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sun Dec 9 11:49:31 2012 +0000 source-hash-e3633f60b349022994e291aa3d1a0c90c3403b2e commit e3633f60b349022994e291aa3d1a0c90c3403b2e Author: Stephan Bergmann <sbergman@redhat.com> AuthorDate: Wed May 16 09:32:51 2012 +0200 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Wed May 16 09:36:38 2012 +0200 fdo#46074 fdo#49948 Ignore corrupted items in Recent Documents ...following up on 4ccb4bda483eb548eb6efb5e2f1952f094522320 "fdo#46074 Ignore corrupted items in Recent Documents" with another problematic scenario found with fdo#49948. Change-Id: I3e7c803813f09c1f031defc2c18cfab6732b1621 # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect bad 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # good: [598083cdb5699e7f45183da8b750815f62ff5485] source-hash-ecb1599ad00e71dfe05f3ae9a71bdce5f7540a40 git bisect good 598083cdb5699e7f45183da8b750815f62ff5485 # good: [cc1fc072dd691da3da43742dfc3fdd126157257b] source-hash-18c661f715a0b6850d30b374e5556dc14a377d2b git bisect good cc1fc072dd691da3da43742dfc3fdd126157257b # good: [fb0ce84a03588593a081ac3a26b2ada2d960b76c] source-hash-1aa91a2d8e7db5cebff5b47f3005f1acff64d25e git bisect good fb0ce84a03588593a081ac3a26b2ada2d960b76c # good: [d9be4b56c2e61bb94c677582dc92419f8468a927] source-hash-ef7a460fa51140782b7ad4d87aa782ca007c56ca git bisect good d9be4b56c2e61bb94c677582dc92419f8468a927 # bad: [6d6e5252d2c81fa930cb89f3eaf0efadf09cb87f] source-hash-e3633f60b349022994e291aa3d1a0c90c3403b2e git bisect bad 6d6e5252d2c81fa930cb89f3eaf0efadf09cb87f # good: [b3713b7e6bccaa3c07695a358f2667f877d007d9] source-hash-9ca02a663c3eee2698eb360dd5dc7afb1951e743 git bisect good b3713b7e6bccaa3c07695a358f2667f877d007d9 # good: [322dea02e8867272a756e7430e689699d2216aad] source-hash-18e6e7d929c2be209407ed2e56b8ec4d5e6c4900 git bisect good 322dea02e8867272a756e7430e689699d2216aad
Aurimas: Thank you so much for the bi-bisect, it was extremely helpful. Thanks to you, I found the commit that causes this extremely quickly :-) 50cb1667020494906afaacb68d4163d1eda527cf is the first bad commit commit 50cb1667020494906afaacb68d4163d1eda527cf Author: Miklos Vajna <vmiklos@suse.cz> Date: Tue May 15 08:56:38 2012 +0200 fdo#49940 dmapper: handle m_bTitlePage when m_nBreakType is zero We used to ignore m_bTitlePage in this case, resulting in wrong 'Default' page style for the first page, instead of 'First Page'. Change-Id: I1899354fb39db4f0eb663fd5233395f2d4a5e72a :040000 040000 3db5b71713e121686687d45d1f9833f4b0da8fc0 5caf6a91d0a08322bef9915c9ae653efff991303 M writerfilter Miklos, can you please have a look? Thank you!
Seems I forgot to check if we're trying to set an empty page name, in which case we shouldn't do anything. I'll fix this in a bit.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8281578b89c3df3fe3452a594f6b21483683638a fdo#53985 DOCX import: don't try to set empty PageDescName 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.
4-0 review: https://gerrit.libreoffice.org/2460
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0a12e1278b2ea6a4a668d610ff3c6a23c5fc6249&h=libreoffice-4-0 fdo#53985 DOCX import: don't try to set empty PageDescName It will be available in LibreOffice 4.0.2. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ceb32f59d96a17c3007ed883fb44bc880673c8e0 crashtesting: UaF on layout of fdo53985-1.docx It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.