List items
Items from the current list are shown below.
Blog
17 Dec 2023 : Day 110 #
Unfortunately I woke up this morning with some kind of Winter ailment: headache, sore throat, cough and all the rest. This has knocked me out for pretty much the entire day, including all of my planned gecko work.
The thing I hate most about being unwell is that it totally throws off all of my plans. I really hate that. It's not just my gecko work, but I had big plans to work on a Rust project today as well.
As a consequence it'll be a short one today, and potentially also for the next couple of days. Hopefully I'll be able to gain momentum just as soon as I'm back to my normal self.
Nevertheless, as yesterday we're continuing to work through the printer code to try to remove the window that's appearing when the print starts. Now that our examination has reached the sailfish-browser code I think we can start calling it a tab now. This is the code we ended up at last night:
This is such a web. Somewhere the parentBrowsingContext going in has to touch the newBC coming out. It looks like the place may be in the EmbedLiteViewChild::InitGeckoWindow() method where we have this:
I'm going to try to short-circuit this by adding the following code to nsWindowWatcher::OpenWindowInternal() before all this happens.
It's building now so it's a good time for me to pause. I'll aim to pick this up again in the morning.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
The thing I hate most about being unwell is that it totally throws off all of my plans. I really hate that. It's not just my gecko work, but I had big plans to work on a Rust project today as well.
As a consequence it'll be a short one today, and potentially also for the next couple of days. Hopefully I'll be able to gain momentum just as soon as I'm back to my normal self.
Nevertheless, as yesterday we're continuing to work through the printer code to try to remove the window that's appearing when the print starts. Now that our examination has reached the sailfish-browser code I think we can start calling it a tab now. This is the code we ended up at last night:
quint32 DeclarativeWebPageCreator::createView(const quint32 &parentId, const uintptr_t &parentBrowsingContext) { QPointer<DeclarativeWebPage> oldPage = m_activeWebPage; m_model->newTab(QString(), parentId, parentBrowsingContext); if (m_activeWebPage && oldPage != m_activeWebPage) { return m_activeWebPage->uniqueId(); } return 0; }Now it's time to check out the m_model which we can see declared in the class header:
QPointer<DeclarativeTabModel> m_model;I've looked through the code a few times now and exactly what's happening is confusing me greatly. It looks very much like the parentBrowsingContext is passed in to creatView() which passes it along to newTab(). This transition causes a name change to browsingContext and this value gets stored with the new tab:
Tab tab; tab.setTabId(nextTabId()); tab.setRequestedUrl(url); tab.setBrowsingContext(browsingContext); tab.setParentId(parentId);There's no particular magic happening here:
void Tab::setBrowsingContext(uintptr_t browsingContext) { Q_ASSERT_X(m_browsingContext == 0, Q_FUNC_INFO, "Browsing context can be set only once."); m_browsingContext = browsingContext; }My concern is that this is the same browsing context that's eventually going to be returned by nsWindowWatcher::OpenWindowInternal(). After we've gone all the way to sailfish-browser and back again the new browser context gets extracted like this:
nsCOMPtr<nsIWebBrowserChrome> newChrome; rv = CreateChromeWindow(parentChrome, chromeFlags, openWindowInfo, getter_AddRefs(newChrome)); // Inside CreateChromeWindow RefPtr<BrowsingContext> parentBrowsingContext = aOpenWindowInfo->GetParent(); Tab tab; tab.setBrowsingContext(parentBrowsingContext); // After CreateChromeWindow nsCOMPtr<nsIDocShellTreeItem> newDocShellItem = do_GetInterface(newChrome); RefPtr<BrowsingContext> newBC = newDocShellItem->GetBrowsingContext();Note that the above isn't real code, it's just a summary of the steps that happen at different stages to give an idea of how the variables are moving around.
This is such a web. Somewhere the parentBrowsingContext going in has to touch the newBC coming out. It looks like the place may be in the EmbedLiteViewChild::InitGeckoWindow() method where we have this:
RefPtr<BrowsingContext> browsingContext = BrowsingContext::CreateDetached (nullptr, parentBrowsingContext, nullptr, EmptyString(), BrowsingContext::Type::Content);This seems to happen when an instance of EmbedLiteViewChild is created.
I'm going to try to short-circuit this by adding the following code to nsWindowWatcher::OpenWindowInternal() before all this happens.
if (!newBC) { bool isForPrinting = openWindowInfo->GetIsForPrinting(); if (isForPrinting) { RefPtr<BrowsingContext> parentBrowsingContext = openWindowInfo->GetParent(); newBC = BrowsingContext::CreateDetached(nullptr, parentBrowsingContext, nullptr, EmptyString(), BrowsingContext::Type::Content); } }Taking a look at this with fresh eyes in the morning will &mash; I'm sure — help. Maybe I'll feel a little more cogent tomorrow. This is as far as I can take it today.
It's building now so it's a good time for me to pause. I'll aim to pick this up again in the morning.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
Comments
Uncover Disqus comments