Flypig's gecko dev diary

Those are per-site overrides, but I was referring to the default user agent. I found this that describes the recommendations:

About Windows/arm64:

About removing arch altogether:


In case someone missed it; the video is up:


I’ve got a bit behind with the discussion here, but thanks for all the comments.

You’re right, rebuilding just for JavaScript changes would be a real pain, but thankfully this bit, at least, can be streamlined. With JavaScript changes I transfer them directly over to the device (or sometimes even edit them on the device). Check out day 94 for a bit more on this.

Only that it’s on my to-do list. Once the WebView render is working, which I’m doing right now, it should be possible to install it without breaking the email client. So once I’m done with this I think it’d be worthwhile me spending some time to get a version others can really try out properly. I’ll post here when that’s available.

Thanks! I wasn’t sure whether to write about it, so glad to hear this. I’m not totally convinced this way was quicker than doing it by hand, but it was more fun :grin:

On the topic of user agents, I wasn’t aware of this aarch64/x86 hack Mozilla are using. That’s really interesting. It’s crazy that this stuff makes a difference, but given that it does, I personally think it’s worth following Mozilla’s lead. I’ll create an issue for it. Thanks for the discussion and links @direc85, @nephros.


I’m happy that the user agent string gets more thought, since it seems to be quite an important piece of the puzzle of getting more sites work properly… Hopefully with a good default user agent string the list of exceptions gets shorter too. And that’s where the community can really chip in!

Making a test release for the community is a nice idea indeed! I don’t remember if it’s just a JSON file on the disk or in a packaged file, but if the testers could change the content themselves, that would be even more helpful!

Thanks for making the avatar wall! I didn’t realize there are already so many contributors… It really is a community effort.

PS. The Rust 1.75 PR nudged forward a bit (compilation in OBS now works), we’re getting closer and closer of it getting merged.


@flypig came to mind, since theres mesa on sfos,
you can use thse env vars that might give more insight on the opengl side


Ive got some though questions that came to mind today while reading the latest entry of the diary.
It seems we are at the detail stage, where things seem to be ok but really are not, and when the size of the effort becomes clear (massive).
Now dont take this as an offence (not intended to be!); Is @flypig the only one working on the browser at the moment ? Noone at jolla picking up the ball? If thats the case, what is Jolla’s comment on this? Id assume the browser is a key component of SFOS product…and as such an upgrade would be due more support from jolla side, one d expect…

1 Like

@flypig good progress! \o/
It seems you have exited browser world and are stepping into wayland lands, thats a good sign, problems yes but somewhere else :slight_smile:
you could try the WAYLAND_DEBUG=1 (or “all” iirc) to complete your logs with the wayland surface creation protocol (it might be qt-wayland doesnt support swapchains?). Its a fairly simple protocol.
It might make sense to run even an opengles, swap-chain based example to validate this hyphothesis…smaller to build and faster to work with!
Keep going @flypigg~~


The issue that @flypig is now trying to figure out sounds a bit like the one I had with Qt Scene Graph recently. I wasn’t properly releasing textures so it kept reserving dmabuf file descriptors and then eventually the app crashed because it run out of fds (or rather I think it tried to use fd > 1024 for something that’s not compatible with such “high” value). Anyway lsof -p output might be worth looking at.


I’m just going to quote @flypig since it’s good to get some inspiration on a slog:

For those who are still following along, or just desperate to get your hands on a build to test, I appreciate it’s slow progress. But each fix is a fix that’s necessary and I remain confident that eventually all of the pieces will fall in to place. This is very definitely a marathon and not a sprint. An Odyssey not a citybreak. We’ll get there!


Rabbitholes be like loooooooooooooooooooong ones, right?


Indeed! In my case, keeping me from doing sailfish work! Oh, no!

1 Like

Seems @flypig finally managed to escape from a particularly deep one. Good to hear you fixed the freezing issue!


Sheesh, was a bit of a read to catch up! And all for the difference in EGL and Egl :wink:

1 Like

@flypig i suggest giving the LIB_GLDEBUG
/ MESA_DEBUG a try. They will generate alot of output but might highlight the failing function right away. Its time for the heavy weapons :stuck_out_tongue:


Thinking about debugging GL code, maybe @flypig, you know or already uses this:

    glDebugMessageCallback(_openGLMessage, 0);

where you can provide a function dealing with GL errors:

static void _openGLMessage(GLenum source _U_, GLenum type, GLuint id, GLenum severity,
                           GLsizei length _U_, const GLchar* message,
                           const void* userParam _U_)
  gboolean warn = TRUE;
  const char *ctype, *cseverity;
  switch (severity)
      cseverity = "LOW";
      cseverity = "MEDIUM";
      cseverity = "HIGH";
      cseverity = "UNKNOWN";
  switch (type)
      ctype = "ERROR";
      ctype = "DEPRECATION";
      ctype = "UNDEFINED";
      ctype = "PORTABILITY";
      ctype = "OTHER";
      warn = FALSE;
  if (warn)
    g_warning("GL CALLBACK: type = %s, severity = %s, id = %d, message = %s",
              ctype, cseverity, id, message);
    g_debug("Visu OpenGL: type = %s, severity = %s, id = %d, message = %s",
            ctype, cseverity, id, message);

I’ve used it to partly understand what was wrong in my GL code. But maybe it’s not appropriated in your case if it’s a transfer issue between GPU and offscreen buffer… Good luck anyway !


If its an opengl transfer, it will show!