when opening https://bugs.freedesktop.org/attachment.cgi?id=96050 for the first few seconds 1/3 is displayed, and then updated to 1/8
tested under Win7x64 LibO 4.2.5.2 show 1/6 count all the time. all pages have vertical layout. LibO 4.4.0.0.alpha0+ (*) I see initial 1/3 count that reaches 1/8 after a few seconds. morevoer only first and last page are in vertical layout, the other being horizontal. so I confirm the page count issue. regarding the layout I don't know which is the correct behaviour. how the original .docx file look in MS Word? (*) Build ID: b9dca968c6fd0ab5ca140c65b0e54d153cd34986 TinderBox: Win-x86@42, Branch:master, Time: 2014-07-18_22:51:20
i don't have access to a MSO install right now, but i encountered the bug when triaging Bug 76550, which also re-used the document.
Not bibisectable: The first bad commit could be any of: db3f8609d22bdb6041bd9ea6780fed54a8907a26 c567bb961271596a852b55742a65e04f0b92ecbb We cannot bisect more! Marking as: Trivial - really an aesthetic thing, lasts a total of 5-6 seconds and then page count is fine. Low - regression so bumped up from lowest
So - I'm highly unconvinced that this is a regression; we do asynchronous word-counting to show the document more quickly to improve load time, and then layout in the background to get the page-count right. Also - the new 'idle' work that the Munich guys are doing should improve this significantly by working much harder to do that layout while not breaking interactivity [ currently it's done with timeouts I suspect ]. Dropping the 'regression' keyword too.
To be honest this is simply expected behaviour. Consider it analogous to loading a long web page - the alternative to figuring out the page count asynchronously is to always wait until the whole document has been analysed, which could be a very long wait. Figuring out the right answer within a few seconds seems perfectly acceptable to me. Setting RESOLVED - NOTABUG
Migrating Whiteboard tags to Keywords: (notBibisectable) [NinjaEdit]