[PATCH] When is KHTMLView done with rendering?

David Faure faure at kde.org
Thu Jun 17 14:18:02 BST 2004


On Thursday 17 June 2004 15:08, Jeroen Wijnhout wrote:
> Hi,
> 
> Hereby I send you a patch for (no. 11 of most hated bugs, but it's my most 
> hated bug)
> Bug 57360: URLs with anchor - sometimes the position is not moved to the 
> anchor
> 
> Description:
> In KHTMLPart::checkCompleted a call to gotoAnchor is performed, however AFAIK 
> this is useless since at the moment of this call there is no guarantee that 
> the layouting is done. Result: KHTML jumps to an arbitrary position since 
> HTMLElementImpl::getUpperLeftCorner(x, y) returns random data (usually it 
> results in jumping to (0,0) though).
> 
> Solution: Create a new (private) slot in KHTMLPart, gotoAnchor. This slots 
> jumps to the anchor if a HTML reference is present in the current URL. This 
> slot is connected to the KHTMLView signal finishedLayout(), which is emitted 
> at the very end of KHTMLView::layout(). When the slot gotoAnchor is invoked, 
> all HTML elements have well defined positions.
> 
> About the "whether or not to jump to the anchor after user interaction" 
> discussion: KHTML will jump to the anchor even after user interaction. In the 
> end this is the best behavior, since this is what the user might expect 
> (after all the HTML reference is clearly visible in the location bar). Also, 
> unsuspecting users will probably be confused when KHTML does not jump to the 
> anchor when they scroll the view a bit.
> 
> Ok to commit? Constructive criticism is welcomed :-)

Small nitpick: why not do the test   if ( !m_url.encodedHtmlRef().isEmpty() )
before actually connecting to the signal?
Then gotoAnchor() will only be called when we actually need to go to an anchor,
as one might expect.

Even more nitpicking: emit finishedLayout() is more common than emit(finishedLayout()),
since emit isn't a function (merely a noop keyword).

Patch looks great otherwise.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kfm-devel mailing list