List items
Items from the current list are shown below.
Blog
22 Dec 2023 : Day 115 #
This morning the build had not completed successfully. There were a few instances of the hidden and isHidden parameters that I'd failed to add. It's quite a web inside the EmbedLite structures with what seems to be every combination of {App, View}, {Thread, Process, Nothing} and {Parent, Child, Interface}. It was always going to be easy to miss something.
Thankfully that's not the disaster it might have been because the idl interface definitions went through their regeneration cycle to create new source and header files. That means I can now do partial builds to check that things are working.
As I add the final arguments to the code I notice that the final resting place of the flag seems to be here in EmbedLiteViewChild:
Another note to myself is to decide whether we need to store isHidden in EmbedLiteViewParent or not. Here's the relevant method signature:
Now that the partial build completed successfully I'm going to run it through the full build again so that I have a package to install. That's necessary for me to be able to build qtmozembed and sailfish-browser against the new header files from these changes.
[...]
It's towards the end of the day now and the build completed successfully. At least, I'm pretty sure it did. I stupidly closed the build output window by accident during the day. But the packages have a modified time of 15:30 today, which sounds about right.
The next step is to find out how to push the hidden flag through to the sailfish-browser front-end. In theory, with the interface changed, if I now try to build qtmozembed against the latest packages I've just built, it should fail in some way. If I find the place it's failing, that should give me a good place to start.
Let's build them and see what happens.
The connection point is supposed to happen in qmozcontext.cpp where the QMozContextPrivate class implements EmbedLiteAppListener:
Since I didn't do a clean rebuild of qtmozembed I'm thinking maybe the reason is that it just didn't know to rebuild some of the files. Let's try it again, but this time with passion.
I've added the hidden parameter to QMozContextPrivate::CreateNewWindowRequested() and let the changes cascade through the rest of the code. There's quite a lot of abstraction in qtmozembed, but despite that the changes all seem quite reasonable and, crucially, result in a new Q_PROPERTY being created to expose the hidden flag to the front end.
After a few build-fail-fix cycles the packages now builds fully without compiler or linker errors. The sailfish-browser code also links against it without issue... but it shouldn't. I probably need to clean out all the existing build first again and give it another go. I've cleaned it out, but sailfish-browser takes a surprising amount of time to complete (nothing compared to gecko, about 20 mins or so, but that's still a lot of code to build).
I've set it going, let's see if there are errors now (there will be!).
[...]
And indeed there are! Thank goodness for that.
The next step will be to create a QSortFilterProxyModel on it so that the pages can be hidden. But it's already late now so this will be a task for tomorrow.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
Thankfully that's not the disaster it might have been because the idl interface definitions went through their regeneration cycle to create new source and header files. That means I can now do partial builds to check that things are working.
As I add the final arguments to the code I notice that the final resting place of the flag seems to be here in EmbedLiteViewChild:
void
EmbedLiteViewChild::InitGeckoWindow(const uint32_t parentId,
mozilla::dom::BrowsingContext
*parentBrowsingContext,
const bool isPrivateWindow,
const bool isDesktopMode,
const bool &isHidden)
At this point the flag is discarded and it should be used for something. This is a note to myself to figure out what.Another note to myself is to decide whether we need to store isHidden in EmbedLiteViewParent or not. Here's the relevant method signature:
EmbedLiteViewParent::EmbedLiteViewParent(const uint32_t &windowId,
const uint32_t &id,
const uint32_t &parentId,
const uintptr_t &parentBrowsingContext,
const bool &isPrivateWindow,
const bool &isDesktopMode,
const bool &isHidden)
Currently this gets stored in a class member, but we don't seem to use it anywhere. It can probably be removed, although then that begs the question of why pass it in at all? I should come back and check this later.Now that the partial build completed successfully I'm going to run it through the full build again so that I have a package to install. That's necessary for me to be able to build qtmozembed and sailfish-browser against the new header files from these changes.
[...]
It's towards the end of the day now and the build completed successfully. At least, I'm pretty sure it did. I stupidly closed the build output window by accident during the day. But the packages have a modified time of 15:30 today, which sounds about right.
The next step is to find out how to push the hidden flag through to the sailfish-browser front-end. In theory, with the interface changed, if I now try to build qtmozembed against the latest packages I've just built, it should fail in some way. If I find the place it's failing, that should give me a good place to start.
Let's build them and see what happens.
$ cd ../qtmozembed/ $ sfdk -c no-fix-version build -d [...] The following 5 packages are going to be reinstalled: xulrunner-qt5 91.9.1-1 xulrunner-qt5-debuginfo 91.9.1-1 xulrunner-qt5-debugsource 91.9.1-1 xulrunner-qt5-devel 91.9.1-1 xulrunner-qt5-misc 91.9.1-1 5 packages to reinstall. [...] Wrote: RPMS/SailfishOS-devel-aarch64/qtmozembed-qt5-tests-1.53.9-1.aarch64.rpm Wrote: RPMS/SailfishOS-devel-aarch64/qtmozembed-qt5-devel-1.53.9-1.aarch64.rpm Wrote: RPMS/SailfishOS-devel-aarch64/qtmozembed-qt5-debugsource-1.53.9-1.aarch64.rpm Wrote: RPMS/SailfishOS-devel-aarch64/qtmozembed-qt5-1.53.9-1.aarch64.rpm Wrote: RPMS/SailfishOS-devel-aarch64/qtmozembed-qt5-debuginfo-1.53.9-1.aarch64.rpm [...]Surprisingly the qtmozembed build all completed without error. What about sailfish-browser?
$ cd ../sailfish-browser/ $ sfdk -c no-fix-version build -d [...] The following 2 packages are going to be downgraded: qtmozembed-qt5 1.53.25+sailfishos.esr91.20231003080118.8b9a009-1 -> 1.53.9-1 qtmozembed-qt5-devel 1.53.25+sailfishos.esr91.20231003080118.8b9a009-1 -> 1.53.9-1 2 packages to downgrade. [...] Wrote: RPMS/SailfishOS-devel-aarch64/sailfish-browser-debugsource-2.2.45-1.aarch64.rpm Wrote: RPMS/SailfishOS-devel-aarch64/sailfish-browser-ts-devel-2.2.45-1.aarch64.rpm Wrote: RPMS/SailfishOS-devel-aarch64/sailfish-browser-settings-2.2.45-1.aarch64.rpm Wrote: RPMS/SailfishOS-devel-aarch64/sailfish-browser-2.2.45-1.aarch64.rpm Wrote: RPMS/SailfishOS-devel-aarch64/sailfish-browser-tests-2.2.45-1.aarch64.rpm [...]Well that's all a bit strange. I thought there would be at least some exposure to some of the elements I changed. I guess I got that wrong.
The connection point is supposed to happen in qmozcontext.cpp where the QMozContextPrivate class implements EmbedLiteAppListener:
class QMozContextPrivate : public QObject, public EmbedLiteAppListener
{
[...]
virtual uint32_t CreateNewWindowRequested(const uint32_t &chromeFlags,
EmbedLiteView *aParentView,
const uintptr_t
&parentBrowsingContext) override;
Compare this with the method it's supposed to be overriding:
class EmbedLiteAppListener
{
[...]
// New Window request which is usually coming from WebPage new window request
virtual uint32_t CreateNewWindowRequested(const uint32_t &chromeFlags,
const bool &hidden,
EmbedLiteView *aParentView,
const uintptr_t
&parentBrowsingContext) { return 0; }
The override should be causing an error.Since I didn't do a clean rebuild of qtmozembed I'm thinking maybe the reason is that it just didn't know to rebuild some of the files. Let's try it again, but this time with passion.
$ cd ../qtmozembed/
$ git clean -xdf
$ sfdk -c no-fix-version build -d
[...]
In file included from qmozcontext.cpp:22:
qmozcontext_p.h:53:22: error: ‘virtual uint32_t QMozContextPrivate::
CreateNewWindowRequested(const uint32_t&, mozilla::embedlite::EmbedLiteView*,
const uintptr_t&)’ marked ‘override’, but does not override
virtual uint32_t CreateNewWindowRequested(const uint32_t &chromeFlags,
^~~~~~~~~~~~~~~~~~~~~~~~
qmozcontext_p.h:53:22: warning: by ‘virtual uint32_t QMozContextPrivate::
CreateNewWindowRequested(const uint32_t&, mozilla::embedlite::EmbedLiteView*,
const uintptr_t&)’ [-Woverloaded-virtual]
[...]
make[1]: *** [Makefile:701: ../src/moc_qmozcontext_p.o] Error 1
Okay, that's more like it. So now I know for sure that this is the place to start.I've added the hidden parameter to QMozContextPrivate::CreateNewWindowRequested() and let the changes cascade through the rest of the code. There's quite a lot of abstraction in qtmozembed, but despite that the changes all seem quite reasonable and, crucially, result in a new Q_PROPERTY being created to expose the hidden flag to the front end.
After a few build-fail-fix cycles the packages now builds fully without compiler or linker errors. The sailfish-browser code also links against it without issue... but it shouldn't. I probably need to clean out all the existing build first again and give it another go. I've cleaned it out, but sailfish-browser takes a surprising amount of time to complete (nothing compared to gecko, about 20 mins or so, but that's still a lot of code to build).
I've set it going, let's see if there are errors now (there will be!).
[...]
And indeed there are! Thank goodness for that.
$ cd ../sailfish-browser/
$ git clean -xdf
$ sfdk -c no-fix-version build -d -p
[...]
../qtmozembed/declarativewebpagecreator.h:37:21: error: ‘virtual quint32
DeclarativeWebPageCreator::createView(const quint32&, const uintptr_t&)’
marked ‘override’, but does not override
virtual quint32 createView(const quint32 &parentId, const uintptr_t &parentBrowsingContext) override;
^~~~~~~~~~
compilation terminated due to -Wfatal-errors.
make[2]: *** [Makefile:988: declarativewebpagecreator.o] Error 1
I've been through and made the changes needed. Ultimately they all flowed through the code rather neatly, touching 12 files in qtmozembed and 10 files in sailfish-browser. Crucially the tab model now has a new HiddenRole role that can be used to hide certain tabs.The next step will be to create a QSortFilterProxyModel on it so that the pages can be hidden. But it's already late now so this will be a task for tomorrow.
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