flypig.co.uk

It was gratifying to finally see the DuckDuckGo main search page appearing with an ESR 91 build of the browser. Even the search suggestions are working nicely. But there's trouble beneath the surface. Dig just a little further and it turns out the search results page shows no results. In terms of search engine utility, this is sub-optimal. I'll need to look in to this and fix it. But it's not the first task I need to tackle today. Although the front page at least looked like it was working yesterday, it relied on some changes that still need to be fully implemented and checked. The easy task is adding an override to the user agent string override list. What I found yesterday is that while an ESR 91 user agent string only works with the correct Sec-Fetch headers, it also has to be the mobile version of the user agent. This works:

Mozilla/5.0 (Mobile; rv:91.0) Gecko/91.0 Firefox/91.0

This fails:

Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Firefox/91.0

All of these things have to align. Updating the ua-update.json.in file in the sailfish-browser repository is straightforward. Just make the change, run the preprocess-ua-update-json batch file and copy the result into the correct folder.

$ git diff data/ua-update.json.in
diff --git a/data/ua-update.json.in b/data/ua-update.json.in
index 584720c0..338b8faf 100644
--- a/data/ua-update.json.in
+++ b/data/ua-update.json.in
@@ -116,0 +116,1 @@
+  "duckduckgo.com": "Mozilla/5.0 (Mobile; rv:91.0) Gecko/91.0 Firefox/91.0"

$ ./preprocess-ua-update-json
[sailfishos-esr91 fbf5b15e] [user-agent] Update preprocessed user agent overrides
 1 file changed, 2 insertions(+), 1 deletion(-)
$ ls ua/
38.8.0  45.9.1  52.9.1  60.0  60.9.1  78.0  91.0
$ cp ua-update.json ua/91.0/

The second task is to check the code changes I made over the last couple of days. I added flags that pass certain user interaction signals on to the engine, such as whether an action was user-performed or not. Yesterday I checked using both gdb and by observing the resulting Sec-Fetch-* headers that the flags were making their way through the system correctly. However what I didn't check — and what I need to check still — is that the flags are correct when different paths are used to get there. For example, the system needs to distinguish between entering a URL in the toolbar and triggering a URL via D-Bus. The resulting request headers should be the same, but the logic for how we get to the same place is different. This is a debugging task. Unfortunately time has run away today already, so I'll have to pick up on the actual task of debugging tomorrow.

If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.