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

Stefano Crocco stefano.crocco at alice.it
Sun Mar 29 16:57:41 BST 2026


On domenica 29 marzo 2026 17:03:41 Ora legale dell’Europa centrale David Faure 
wrote:
> 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.

That's what I thought. Thanks for the information. I'll look into fixing it.

Stefano




More information about the Kde-frameworks-devel mailing list