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