words crash, help needed

[Sebastian Sauer]

Seems meanwhile I found the reason why it crashes thanks to your hint :) The 
fix is at http://pastebin.com/fsNFBwqY and the reason was that even when the 
line wasn't fitting (cause it had a width of zero for example) we still added 
one character to it. Will test a bit more, add an infinite loop test and the 
commit. Guess we can probably still apply your idea as Q_ASSERT (and comment) 
to make sure that a) we are dealing with the proper frames and b) others are 
able to understand what that code is supposed to do / how things are working 
together.

On Wednesday 15 June 2011 13:52:22 Sebastian Sauer wrote:
> Dag Andersen wrote:
> > I'm looking into a crash which happens when textshapes is edited and the
> > shape is not on page 1. This is a general case of header/footer crash
> > reported in: https://bugs.kde.org/show_bug.cgi?id=273945
> > 
> > AFAICS the problem is in KWRootAreaProvider::provide().
> > It seems to mix up which page number to use when searching for frames on
> > a page. I don't fully understand how it is meant to work so I need help
> > with that.
> > The att. hack seems to fix the problem but is, well, just a hack.
> 
> Thank you so much for the patch. I would suggest to change the patch to;
> 
> QList<KWFrame *> frames;
> if (KWord::isHeaderFooter() // m_textFrameSet->frameCount() > 0) { // work
> around bug 273945
>     frames = kwdoc->frameLayout()->framesOn(m_textFrameSet, m_textFrameSet-
> 
> >pageManager()->page(m_textFrameSet->frames().at(0)->shape()).pageNumber())
> >;
> 
> } else {
>     frames = kwdoc->frameLayout()->framesOn(m_textFrameSet, pageNumber);
> }
> 
> to make sure that we only fall into the workaround-case if we are dealing
> with headers/footers. And then please commit. I did some tests and it
> indeed seems there are no regressions with the patch. So, great work! :-)
> 
> How it's meaned to work;
> 
> Every header/footer frameset can hold a collection of n frames. The first
> frame in that collection is the "master frame" while all following ones are
> copy-frames. Copy-frames do mirror the master-frame to display the same
> content within n different shapes. We can have multiple framesets for
> headers and footers cause every page-style gets it's own
> header/footer-frameset.
> 
> What we do now in that framesOn-line is to fetch all the frames that are
> already known in the frameset we are dealing with. We determinate the
> frames that are on a page by using there absolutePositions.
> 
> Now what the patch changes is that we don't catch the copy-frames any
> longer and deal with them but always take the master-frame and use that
> one for every root-area (so, also for those root-areas that are supposed
> to use the copy- frame).
> 
> The question now is why it crashes if we are using the copy-frame/shape
> rather then the master-frame/shape? That's what I wasn't able to figure
> out yet :-/ But then the patch shows that we probably don't need to use
> copy-frames at all what would make the code way more easy... Will look
> into that within next days as time permits.
> 
> So, all in all: thanks Dag for the great investigation+hint+fix :-)