List items
Items from the current list are shown below.
Blog
15 Feb 2024 : Day 157 #
The new gecko packages completed their build during the gap. I'm not expecting anything special from them, apart from the debug output that I added yesterday having been removed. But it will be nice to test whether the packages are working. If they are that means I'll have dealt with the session history issues and the actor issues and it'll be time to wind back down the stack to checking DuckDuckGo.
I've just now fired up sailfish-browser and all of the JavaScript errors seem to have been resolved. If nothing else, that's pleasing to see. So now it's time to return to DuckDuckGo again.
You'll recall that I spent a long time getting DuckDuckGo to work. The main problem was the Sec-Fetch-* headers. This allowed the main search page to load. But there was still an issue in that the search results weren't being displayed. I thought this could potentially be related to the session history issue, which is why I started looking at it. But I wasn't at all certain.
Now that the session history is fixed and the JavaScript output is clean, there's a small chance this will have fixed DuckDuckGo as well.
And it has! Searching with DuckDuckGo now produced nice results. And the page feels nice and smooth as well. With the Forwards and Back buttons now also working as expected, it's really starting to feel like a usable browser finally.
But my euphoria is short-lived. I'm able to get the browser into a state where DuckDuckGo is no longer working correctly: it just displays a blank page again.
After closing and firing up the browser again everything works as expected again.
It takes me ages to figure out how to get it back into the state where DuckDuckGo is broken. The breakage looks the same as the Sec-Fetch-* header issues that we were experiencing a couple of weeks back. If that's the case, then it's likely there's some route to getting to the DuckDuckGo page that's getting the wrong flags from the user interface and then offering up the wrong Sec-Fetch-* headers as a result.
What do I mean by a route? I mean some set of interactions to get there: loading the page from the history, a bookmark, the URL bar, pressing back, as a page loaded from the command line. All of these are routes and each will potentially need slightly different flags so that the gecko engine knows what's going on and can send the correct Sec-Fetch-* headers to match.
I thought I'd fixed them all, but it would have been easy to miss some. And so it appears.
So I try all the ways to open the page I can think of from different starting states. After having exhausted what I think are all the routes I realise I've missed something important.
So far I've been running the browser from the command line each time. What if the issue is to do with the way the browser is starting up?
Starting the browser from the command line isn't the same as starting it by pressing on its icon in the app grid. There are multiple rasons for this, but the most significant two are:
To find out what's going wrong I need to establish the Sec-Fetch-* header values that are being sent to the site. That's going to be a little tricky because when launching from the app grid there's no debug output being sent to the console. But it might be possible to extract the same info from the system log. Let's try it:
But as I write this I'm hurtling towards King's Cross Station on the train and due to arrive shortly. So I'll have to leave that question open until this evening.
[...]
It's the evening now, so time to check out the logging from the SailJailed browser. Before running it I want to forcefully enable network logging. This will be easier than configuring a special environment for it.
I've made some amendments to the Logger.js directly on-device for this:
Maybe a caching issue? Let's try deleting the profile, killing any running booster processes and trying again.
When running the browser from the launcher there's an added complication that usually the booster is still running in the background for performance reasons. So changes to the browser code and files may not always be applied if this is the case. After killing the booster processes, this seems to have been fixed.
After this additional investigation I'm satisfied that this doesn't look like an issue with the code after all.
I'm going to leave it there for today. Tomorrow I'll be looking for a completely new task to work on. But I think the browser has got to the stage where it would be worth having more hands to test it, so the next task may be to figure out how that can happen.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
I've just now fired up sailfish-browser and all of the JavaScript errors seem to have been resolved. If nothing else, that's pleasing to see. So now it's time to return to DuckDuckGo again.
You'll recall that I spent a long time getting DuckDuckGo to work. The main problem was the Sec-Fetch-* headers. This allowed the main search page to load. But there was still an issue in that the search results weren't being displayed. I thought this could potentially be related to the session history issue, which is why I started looking at it. But I wasn't at all certain.
Now that the session history is fixed and the JavaScript output is clean, there's a small chance this will have fixed DuckDuckGo as well.
And it has! Searching with DuckDuckGo now produced nice results. And the page feels nice and smooth as well. With the Forwards and Back buttons now also working as expected, it's really starting to feel like a usable browser finally.
But my euphoria is short-lived. I'm able to get the browser into a state where DuckDuckGo is no longer working correctly: it just displays a blank page again.
After closing and firing up the browser again everything works as expected again.
It takes me ages to figure out how to get it back into the state where DuckDuckGo is broken. The breakage looks the same as the Sec-Fetch-* header issues that we were experiencing a couple of weeks back. If that's the case, then it's likely there's some route to getting to the DuckDuckGo page that's getting the wrong flags from the user interface and then offering up the wrong Sec-Fetch-* headers as a result.
What do I mean by a route? I mean some set of interactions to get there: loading the page from the history, a bookmark, the URL bar, pressing back, as a page loaded from the command line. All of these are routes and each will potentially need slightly different flags so that the gecko engine knows what's going on and can send the correct Sec-Fetch-* headers to match.
I thought I'd fixed them all, but it would have been easy to miss some. And so it appears.
So I try all the ways to open the page I can think of from different starting states. After having exhausted what I think are all the routes I realise I've missed something important.
So far I've been running the browser from the command line each time. What if the issue is to do with the way the browser is starting up?
Starting the browser from the command line isn't the same as starting it by pressing on its icon in the app grid. There are multiple rasons for this, but the most significant two are:
- When launched from the app grid the sandbox is used. It's not used when launched from the command line.
- When launched from the app grid the booster is used, unlike when launched from the command line.
To find out what's going wrong I need to establish the Sec-Fetch-* header values that are being sent to the site. That's going to be a little tricky because when launching from the app grid there's no debug output being sent to the console. But it might be possible to extract the same info from the system log. Let's try it:
$ devel-su journalctl --system -f [...] booster-browser[14470]: [D] unknown:0 - Using Wayland-EGL autologind[5343]: library "libutils.so" not found autologind[5343]: library "libcutils.so" not found autologind[5343]: library "libhardware.so" not found autologind[5343]: library "android.hardware.graphics.mapper@2.0.so" not found autologind[5343]: library "android.hardware.graphics.mapper@2.1.so" not found autologind[5343]: library "android.hardware.graphics.mapper@3.0.so" not found autologind[5343]: library "android.hardware.graphics.mapper@4.0.so" not found autologind[5343]: library "libc++.so" not found autologind[5343]: library "libhidlbase.so" not found autologind[5343]: library "libgralloctypes.so" not found autologind[5343]: library "android.hardware.graphics.common@1.2.so" not found autologind[5343]: library "libion.so" not found autologind[5343]: library "libz.so" not found autologind[5343]: library "libhidlmemory.so" not found autologind[5343]: library "android.hidl.memory@1.0.so" not found autologind[5343]: library "vendor.qti.qspmhal@1.0.so" not found [...]It looks like the logging output is all there. The next step is to figure out a way to set the EMBED_CONSOLE="network" environment variable, so that we can capture the headers used.
But as I write this I'm hurtling towards King's Cross Station on the train and due to arrive shortly. So I'll have to leave that question open until this evening.
[...]
It's the evening now, so time to check out the logging from the SailJailed browser. Before running it I want to forcefully enable network logging. This will be easier than configuring a special environment for it.
I've made some amendments to the Logger.js directly on-device for this:
vim /usr/lib64/mozembedlite/chrome/embedlite/content/Logger.jsThe changes applied are the following, in order to force the "extreme" network logging to be used:
[...]
get stackTraceEnabled() {
return true;
//return this._consoleEnv.indexOf("stacktrace") !== -1;
},
get devModeNetworkEnabled() {
return true;
//return this._consoleEnv.indexOf("network") !== -1;
},
[...]
Next we must set the logger running, also on the device:
$ devel-su journalctl --system -f | grep "dbus-daemon" > sailjail-log-01.txtAnd finally run sailfish-browser. The DuckDuckGo page loads, but doesn't render. That's good: that's the bug we want to examine. After closing the browser down I'm left with a surprisingly tractable 80 KiB log file to investigate:
$ ls -lh sailjail-log-01.txt -rw-rw-r-- 1 defaultu defaultu 80.0K Feb 13 22:35 sailjail-log-01.txtThe bits we're interested in are the Sec-Fetch-* request headers. This is what's in the log file for these:
[ Request details ------------------------------------------- ]
Request: GET status: 200 OK
URL: https://duckduckgo.com/?t=h_
[ Request headers --------------------------------------- ]
Host : duckduckgo.com
User-Agent : Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101
Firefox/91.0
Accept : text/html,application/xhtml+xml,application/xml;q=0.9,
image/webp,*/*;q=0.8
Accept-Language : en-GB,en;q=0.5
Accept-Encoding : gzip, deflate, br
Connection : keep-alive
Cookie : l=wt-wt
Upgrade-Insecure-Requests : 1
Sec-Fetch-Dest : document
Sec-Fetch-Mode : navigate
Sec-Fetch-Site : none
Sec-Fetch-User : ?1
If-None-Match : "65cbc605-4716"
Going back to the non-sandboxed run, below are the equivalent headers sent. There are two here because the browser is downloading a second file.
[ Request details ------------------------------------------- ]
Request: GET status: 200 OK
URL: https://duckduckgo.com/?t=h_
[ Request headers --------------------------------------- ]
Host : duckduckgo.com
User-Agent : Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101
Firefox/91.0
Accept : text/html,application/xhtml+xml,application/xml;q=0.9,
image/webp,*/*;q=0.8
Accept-Language : en-GB,en;q=0.5
Accept-Encoding : gzip, deflate, br
Connection : keep-alive
Cookie : l=wt-wt
Upgrade-Insecure-Requests : 1
Sec-Fetch-Dest : document
Sec-Fetch-Mode : navigate
Sec-Fetch-Site : none
Sec-Fetch-User : ?1
If-None-Match : "65cbc606-4716"
[ Request details ------------------------------------------- ]
Request: GET status: 304 Not Modified
URL: https://content-signature-2.cdn.mozilla.net/chains/remote-settings.
content-signature.mozilla.org-2024-03-20-10-07-03.chain
[ Request headers --------------------------------------- ]
Host : content-signature-2.cdn.mozilla.net
User-Agent : Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101
Firefox/91.0
Accept : */*
Accept-Language : en-GB,en;q=0.5
Accept-Encoding : gzip, deflate, br
Connection : keep-alive
Sec-Fetch-Dest : empty
Sec-Fetch-Mode : cors
Sec-Fetch-Site : cross-site
If-Modified-Since : Tue, 30 Jan 2024 10:07:04 GMT
If-None-Match : "b437816fe2de8ff3d429925523643815"
To be honest I'm a bit confused by this: for the initial request there are no difference between the values provided for the Sec-Fetch-* headers in either case. I was expecting to see a difference.Maybe a caching issue? Let's try deleting the profile, killing any running booster processes and trying again.
$ mv ~/.local/share/org.sailfishos/browser/.mozilla/ \
~/.local/share/org.sailfishos/browser/mozilla.bak
$ ps aux | grep browser
4628 defaultu /usr/bin/invoker [...] --application=sailfish-browser
4640 defaultu /usr/bin/firejail [...] --application=sailfish-browser
4674 defaultu /usr/libexec/mapplauncherd/booster-browser
--application=sailfish-browser
4675 defaultu booster [browser]
4702 defaultu grep browser
6184 defaultu /usr/bin/invoker --type=silica-session [...]
--application=jolla-email
6243 defaultu /usr/bin/firejail [...] --application=sailfish-browser
6248 defaultu /usr/bin/firejail [...] --application=jolla-email
6442 defaultu /usr/libexec/mapplauncherd/booster-browser
--application=jolla-email
6452 defaultu booster [browser]
$ kill -1 4640
$ kill -1 6243
After deleting the browser's local config storage and killing the SailJail/booster processes, DuckDuckGo then works successfully again. So probably it was a caching issue.When running the browser from the launcher there's an added complication that usually the booster is still running in the background for performance reasons. So changes to the browser code and files may not always be applied if this is the case. After killing the booster processes, this seems to have been fixed.
After this additional investigation I'm satisfied that this doesn't look like an issue with the code after all.
I'm going to leave it there for today. Tomorrow I'll be looking for a completely new task to work on. But I think the browser has got to the stage where it would be worth having more hands to test it, so the next task may be to figure out how that can happen.
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