[PATCH] When is KHTMLView done with rendering?

Jeroen Wijnhout wijnhout at science.uva.nl
Sat Jun 19 10:38:05 BST 2004


> On Friday 18 June 2004 19:10, David Faure wrote:
>> > I propose the following:
>> > o If url.hasRef() is true, we should jump to an anchor, either
>> delayed or directly.
>> > o If urlcmp( url.url(), m_url.url(), true, true ) && !args.reload &&
>> >     !args.redirectedRequest() && !args.doPost() && !isFrameSet
>> >   is true, we can be sure the page is not modified, reloading is not
>> > necessary.
>> > I'm not too sure about the !isFrameSet, what is it for?
>>
>> If this KHTMLPart is a frameset, then it contains child KHTMLParts
>> (one per frame), which each have a KHTMLView. I think the idea of the
>> code here is that the frame will handle the "jump to anchor" itself,
>> the frameset doesn't have to do anything.
>
> Ok, I will change  "if url.hasRef()" to "if url.hasRef() &&
> !isFrameSet".

Hmm that isn't completely satifactory either. Try the attached patch and
goto http://kde.org/info/3.1.1.php#binary. Sometimes KHTML jumps to
#binary, sometimes it doesn't (it gives a "cannot find anchor 'binary'"
error message in the debug output). The signal finishedLayout is emitted
and connected to gotoAnchor, so that's not the problem.

It seems that although the layouting is finished the part in which the
#binary anchor is located is not _loaded_ completely. Therefore nothing is
known about the anchor #binary. So it seems that for pages with frames
more work needs to be done to fix this bug. Any ideas?

Btw, I will commit this patch if no one objects, it is pretty much a small
correction on the previous patch.

best,
Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: khtml_anchor_bug_2.diff
Type: text/x-diff
Size: 1958 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040619/79ad4c2b/attachment.diff>


More information about the kfm-devel mailing list