Question about KParts::NavigationExtension::openUrlNotify and KParts::ReadOnlyPart::setUrl()

David Faure faure at kde.org
Sun Mar 29 16:03:41 BST 2026


On Sunday, 29 March 2026 14:59:59 Stefano Crocco wrote:
> Hello to everyone,
> in the documentation for KParts::NavigationExtension::openUrlNotify, it's 
> stated that the hosting browser can be query the new URL via 
> KParts::Part::url(). I think this means that the openUrlNotify signal must be 
> emitted after calling ReadOnlyPart::setUrl(): is this correct?

Yes, clearly, based on the documentation.
In practice I'm not sure it matters.
It's about creating a new history entry, which will be updated later anyway.

But yeah, if setUrl is called first, urlChanged() is emitted,
which triggers KonqView::updateUrl (which updates m_url),
and when doing openUrlNotify, KonqView::slotOpenURLNotify() uses
the updated m_url in KonqView::updateHistoryEntry.

> I'm asking this question because I noticed that in Konqueror WebEnginePart, 
> the openUrlNotify signal is emitted when starting loading the URL but setUrl 
> is called when it has finished loading. While I don't think this is causing any 
> issue right now, I decided that using the expected sequence of operations 
> would be better, so I moved the call to setUrl() to when the URL starts 
> loading. This has caused other problems, however, so before I start trying 
> fixing them I'd like to be sure I'm understanding correctly how things should 
> work.

KHTMLPart did setUrl() in openUrl(). I think it's more correct than at the end of loading.
Imagine the loading takes forever and the user abort it. Shouldn't the URL still be
correct, for reloading/bookmarking/any other action that depends on the URL?

Otherwise the URL of the previous page might be used erroneously.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 525 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20260329/f3091f0a/attachment.sig>


More information about the Kde-frameworks-devel mailing list