Query regarding how events are received in WebPositive

Hi all.

I’ve been debugging #11273 ([WebPositive] show icons for local files (easy)) – Haiku and have a possible fix but have doubts.

Issue: Files opened in WebPositive have tab title as empty. I added few logs and compared opening a url and a file.

There’s a function called BrowserWindow::TitleChanged that’s called twice for a url but only once for a file. First call sets label as empty then second label sets the actual label in tab title.

Could someone point me out as to how TitleChanged is hit in WebPositive? I couldn’t directly grep TitleChanged func in haiku codebase. Is it something with the MessageReceived event?

That’s part of the WebPage API from haikuwebkit. It seems to come from a TITLE_CHANGED message with a title field, which is dispatched from the FrameLoaderClient. Given the comment in dispatchDidCommitLoad, it seems it is cleared on purpose on every load, and then dispatchDidReceiveTitle is called when there is indeed a title.

To complete this, the “title” will usually come from the HTML “title” element. This should work for local HTML files as well. I think WebKit also generates a fake title for images (with the image size and other information). But for other file types, there is no title. Maybe the filename could be shown instead if we don’t already do this.

But I’m not sure how this relates to icons. For icons, there is a two-step process currently:

  • When WebKit parses the HTML and requests from HTTP, it will look for a favicon. This can be set from inside the HTML page (using meta attributes, or javascript), and there is a fallback to https://thewebsite/favicon.ico (where “thewebsite” is replaced with the name of the website).
  • For files, the fallback to favicon.ico can’t work, since there is no website to fetch from. The other part should still work for HTML files.
  • I think the function to have favicons at all is a bit broken in general because of #18291 ([WebPositive] favicons are not displayed in url bar (regression)) – Haiku. So maybe it would be a good idea to first investigate and fix that?

Thanks for the help! I looked up the related codearea and found this function DOMImplementation::createDocument

Through above, we are returning object of different types based on input contentType and other fields. For image, ImageDocument class is used. We are calling setTitle only in this type of <>Document class. This corroborates the fact that images opened have titles.

If above logic is accurate, we’ll need to add a setTitle call in other content type to get the text on tab bar. + Add the text logic in localized string part section similar to imageTitle