flypig.co.uk

It's been two weeks since I paused my gecko dev diary, aside from a one-off intermediate blip. As anyone who's been following along will know, the pause was so I could take part in a Book Dash. That finished at the end of last week; if you're interested in reading about my Book Dash experience you'll find a summary on my blog.

Although I wasn't able to do much work on gecko myself during the gap, that didn't stop others from hacking away at it. As explained in the blip, mal, keto and direc85 continued working to get all three architectures set up and building correctly on OBS. That's a big step forwards, because it means anyone can now add the OBS repository to their device and test the packages for real.

Since then Raine, who you'll know from earlier entries, has also been working on the code. He submitted several changes which, when taken together, get the APZ functionality back up and running.

APZ functionality? That sounds a bit technical.

APZ stands for Async Pan/Zoom, which, to boil it down even further, essentially means "Touch input". You may recall that, before the gap, rendering had just starting working, but touch input was broken. That meant you could see what was at the top of the page, but there was no way to scroll around, zoom in or out, or in fact interact with the page at all.

APZ is pretty essential browser functionality.

Raine made two essential changes. First he ensured that the time stamps being passed in to the multi-touch event methods are set correctly:

diff --git a/embedding/embedlite/EmbedLiteView.cpp b/embedding/embedlite/EmbedLiteView.cpp
index 0d6ef9f98780..6b1693255f07 100644
--- a/embedding/embedlite/EmbedLiteView.cpp
+++ b/embedding/embedlite/EmbedLiteView.cpp
@@ -326,7 +326,7 @@ EmbedLiteView::ReceiveInputEvent(const EmbedTouchInput &aEvent)
   NS_ENSURE_TRUE(mViewImpl,);
 
   mozilla::MultiTouchInput multiTouchInput(static_cast(aEvent.type),
-                                           aEvent.timeStamp, TimeStamp(), 0);
+                                           aEvent.timeStamp, TimeStamp::Now(), 0);
 
   for (const mozilla::embedlite::TouchData &touchData : aEvent.touches) {
     nsIntPoint point = nsIntPoint(int32_t(floorf(touchData.touchPoint.x)),

Without this change a zero timestamp is passed in, which prevents touch event "deltas" from being calculated correctly.

A "delta" is a fancy term used for a "difference". This tends to be calculated as the difference between the positions before and after, divided by the difference between the timestamps:

$$
\frac{p_2 - p_1}{t_2 - t_1},
$$
where $p_1, p_2$ are the positions of the current and previous touch respectively and $t_1, t_2$ are the times at which they occurred. As you can imagine, if $t_1$ and $t_2$ are both zero, you end up trying to divide by zero, which you can't do, causing touch input to break.

So setting those timestamps correctly is essential.

That was a change on the EmbedLite side (the Sailfish OS specific code). But there was also a change on the gecko side to ensure the following bit of code is skipped:

bool gfxPlatform::AsyncPanZoomEnabled() {
#if !defined(MOZ_WIDGET_ANDROID) && !defined(MOZ_WIDGET_UIKIT) && !defined(MOZ_WIDGET_QT)
  // For XUL applications (everything but Firefox on Android)
  // we only want to use APZ when E10S is enabled. If
  // we ever get input events off the main thread we can consider relaxing
  // this requirement.
  if (!BrowserTabsRemoteAutostart()) {
    return false;
  }
#endif
  [...]

Without this change the gfxPlatform::AsyncPanZoomEnabled() method returns false, blocking touch input from working.

With these two changes integrated the touch interface now works, pretty much as expected: you can pan by dragging, zoom by pinching, and select links by tapping.

That means we're actually at what I'd call "usable browser" state, which is pretty phenomenal.

Usable, but not yet pleasant or functionally complete. There are still many other small changes to change and hooks to hook. Things like PDF printing of pages, user agent string configuration, WebRTC, playing video and audio...

The list is extensive. But that's what we have an issue tracker for and that's why it's crucial to maintain momentum and keep the development going.

Alright, that's it for today. We're into stage 3 now, which should involve lots of smaller fixes. That means I should hopefully be able to pick up some speed in these dev diaries.

Will we get a working browser by Christmas? I wouldn't want to commit to it, but we should certainly be able to make good progress before then.

This is also the best time for others to get involved. There are three main things to focus on:

1. Applying existing patches. We don't want to apply patches unnecessarily, but where they're needed to fix bugs or restore functionality, we should get them applied.
2. Adjusting the embedlite privileged JavaScript to match the new APIs. Some things changed since ESR 78 and they need fixing.
3. Fixing new bugs by delving in to the gecko C++ or browser Qt code. Hopefully there will be fewer of these.

We already have a bunch of issues related to these on the tracker and the list will grow over time. If you're comfortable with C++ but not particularly familiar with the gecko code then the first type of task would be a great way to get involved. If JavaScript is more your thing then the second type of task would no doubt suit your skills. If you really want to get to grips with the innards of gecko and how it works on Sailfish OS, then go for the third.

Personally, I'm planning to start with the second type of task. There's already a torrent of errors being generated by the JavaScript code which I'd love to clean up. More on this tomorrow.

If you'd like to catch up on all the diary entries before the gap, they're all available on my Gecko-dev Diary page.