However, some time ago I played Duotrigordle and I thought what it would be great to have it in Russian. And that lead me to another pet project in a very uncommon environment for me. It’s a pure client word guessing game. Of course, I could use Scala.js for that, but I wanted to keep it light, and also, to have a little bit practice in the common frontend tools. It took couple of months for me to create it from scratch. It still have a nasty hard to reproduce bug, but it’s available at 32.limansky.me, so you can play it. Here I’d like to share some details and thoughts about this project development.

I decide to use pure React because, to be honest, I have a little experience with it already. While we developed Продажи.рф at 1-OFD, we all participated in frontend development a little bit. But, since 32rdle is a pure client side game, I decided not to use any React based frameworks. I chose wouter for routing and zustand for state management, because both of them are simple and lightweight libraries. Also I used Vite and Vitest because it’s easy to setup and fast. Of course, I used TypeScript for coding, because I have no idea how and why people write any code without of types.

Fortunately I already had Neovim setup (my dotfiles) with LSP, so I’ve been kind of ready to start.

Here is a list of top 5 problems I faced with from hard to easy:

1. CSS.
2. More CSS.
3. Algorithms.
4. React itself.
5. Components organization.

This list is not that I initially expected. Well, I knew what CSS is hard, but I didn’t expect it to be that hard. Secondly, I expected React to be a bigger problem for me. I still have some problems with understanding hooks, and what and when, should I use, but it is not the major problem. The two last points are related. At some point I’ve found that I put to much business logic into the components. In my case that lead to the calculation duplication. For example boards can calculate their state themselves according to the entered words and the guessed word. However, these states are also required for the status bar component. So I had to change the interface of the components several times to avoid unnecessary calculation repetitions.

Some pieces of code I wrote still looks weird for me, and I feel like I do something wrong way. For example I need a path parameter to be a number.

const gameParser = (path: string, loose?: boolean): { pattern: RegExp, keys: string[] } => {
  if (path === "/daily/:id") {
    const named = parse(/^\/daily\/(?<id>[0-9]+)$/);
    return { pattern: named.pattern, keys: ['id'] };
  }

  return parse(path, loose);
};

This condition is looks ugly for me, but it works, and I have no idea how to make it better.

The whole code is available at github.

Tuples in Scala 3

Let’s take a look at tuples in Scala 3. In previous versions of Scala we had the famous Tuple1 .. Tuple22 classes defined like:

final case class Tuple2[+T1, +T2](_1: T1, _2: T2) 
    extends Product2[T1, T2] 
    with Product 
    with Serializable

These classes are available in Scala 3 too, but there are another classes for tuples:

sealed trait Tuple extends Product
object EmptyTuple extends Tuple
trait NonEmptyTuple extends Tuple
case class [+H, +T <: Tuple] *:(head: H, tail: T) extends NonEmptyTuple

I simplified the code a little bit, but the idea is the same. This is something new in the Scala library, but it looks very familiar. Actually it’s a list with different types of its’ elements. This called the Heterogeneous list, or HList! In Scala 2 we had HLists in shapeless, and also in some other libraries. Having heterogeneous lists in the standard library makes a lot of sense, and now we don’t need any other HList implementation. Scala 3 tuples has a lot of useful functions, for example they can be converted to List, be concatenated, zipped, etc.:

scala> val t = (5, "String", 3d, false)
val t: (Int, String, Double, Boolean) = (5,String,3.0,false)

scala> t.toList
val res0: List[Tuple.Union[t.type]] = List(5, String, 3.0, false)

scala> val x = t.drop(2)
val x: (Double, Boolean) = (3.0,false)

scala> t ++ x
val res1: Int *: String *: Double *:
  scala.Tuple.Concat[Boolean *: scala.Tuple$package.EmptyTuple.type, x.type]
    = (5,String,3.0,false,3.0,false)

Moreover, Scala 3 provides mechanisms similar to shapeless Generics making possible to convert from algebraic data types (if you are not familiar with algebraic data types, to understand further examples you might think that it’s just case classes) to tuples and back. Let’s take a look at these features.

Tuples from case classes

The Tuple companion object contains method fromProductTyped which allows us to construct tuple from a case class:

scala> case class Foo(a: String, b: Int)
// defined case class Foo

scala> Tuple.fromProductTyped(Foo("test", 5))
val res2: (String, Int) = (test,5)

With this knowledge we can try to implement SqlSaver from “Getting started with shapeless” post for Scala 3. So, let’s do it. The type class definition itself is unchanged:

trait SqlSaver[A] {
  def save(statement: PreparedStatement, idx: Int)(a: A): Int
}

However, there is a new syntax for implicits in Scala 3. When we need to use an implicit instance we use using keyword. So, now the summoner method will look like:

object SqlSaver {
  def apply[T](using ss: SqlSaver[T]): SqlSaver[T] = ss
}

When we need to declare an instance of type class (or any other implicit), we use given keyword. With this new syntax instances of SqlSaver for primitive types become:

object SqlSaver {
  // ...
  given SqlSaver[Int] = createSimpleSaver((a, s, i) => s.setInt(i, a))
  given SqlSaver[String] = createSimpleSaver((a, s, i) => s.setString(i, a))
  given SqlSaver[Double] = createSimpleSaver((a, s, i) => s.setDouble(i, a))
  given SqlSaver[BigDecimal] = createSimpleSaver((a, s, i) => s.setBigDecimal(i, a.underlying))
  given SqlSaver[LocalDateTime] = 
    createSimpleSaver((a, s, i) => s.setTimestamp(i, Timestamp.valueOf(a)))

In this example we created anonymous instances, but it’s also possible to give names to the type class instances, e.g.:

  given intSaver: SqlSaver[Int] = createSimpleSaver((a, s, i) => s.setString(i, a))

Now, let’s implement SqlSaver instances for tuples. As it was before for HNil (empty HList), for the empty tuple it just does nothing:

  given SqlSaver[EmptyTuple] = createSaver((_, _, i) => i)

For non-empty tuple we need SqlSaver for head, to save left tuple member and SqlSaver for the tail, like we did before for :: (non-empty HList):

  given [H, T <: Tuple](using hSaver: SqlSaver[H], tSaver: SqlSaver[T]): SqlSaver[H *: T] = 
    new SqlSaver[H *: T] {
      override def save(statement: PreparedStatement, idx: Int)(t: H *: T): Int = {
        val next = hSaver.save(statement, idx)(t.head)
        tSaver.save(statement, next)(t.tail)
      }
    }

Here, we created instance for tuple dependent on the instances for the H and T via using keyword.

Finally, we can create instance for Products, which will convert a case class to tuple, and then call SqlSaver for the tuple to really save the data. However, to do it we need to know the exact tuple type. For example, if the product is case class Foo(a: String, b: Int) then the tuple type will be (String, Int), or that’s the same String *: Int *: EmptyTuple. In shapeless for Scala 2, we used Generic to convert ADTs to and from HLists. It also was a type link between ADTs and their HList representations. In Scala 3, we have class Mirror to connect products and coproducts with tuples both on the type and the value level.

To achieve that Mirror trait contains several type members. The MirroredElemTypes is a tuple type we are looking for. Bearing this in mind, we can connect the mirror with the SqlSaver in the using part of the type class instance declaration:

import scala.deriving.Mirror
// ...

  given [P <: Product](using m: Mirror.ProductOf[P],
                            ts: SqlSaver[m.MirroredElemTypes]
                      ): SqlSaver[P] = new SqlSaver[P] {
    override def save(statement: PreparedStatement, idx: Int)(t: P): Int =
      ts.save(statement, idx)(Tuple.fromProductTyped(t))
  }

Here you can see another new cool feature of Scala 3. Previously we had to use Aux pattern to make types depend on each other. Now, we can just use type members in other function parameters or even as a result type.

Summary

Scala 3 brings us a lot of new features. Personally I like the way the language is evolving. Even if some things a bit controversial most of the stuff makes Scala more readable, and gives us tools to build standard solutions for standard problems. Typelevel programming in general is a complex topic, but the new code looks a bit simpler, and also it doesn’t require external dependencies.

I found that for big or medium size teams git flow is quite practical. What I didn’t like about it, is that it requires to change the version all the time you change the branch in your repository. At some point I took responsibilities of release engineer in our team. Since I’m very lazy to do all of this styff I came up with some Scala code in the project catalog of my current working project. Later I rewrote it as an sbt plugin.

So, what can it do for you?

Let’s start with git flow. The typical git flow process have following branches:

• master - contains stable releases. Only tested releases are merged here, and only stable artifacts are build from this branch (no snapshots allowed).
• develop - current development release. Features for the next release are going here. We can define the version as a next minor version: “(last version + 0.1)-SNAPSHOT”.
• release/x.y.z - release branches. These branches are for upcoming releases during stabilization. In our team we do not have develop branch, but several release branches. For me, it’s more clear. The versions on this branch is x.y.z-SNAPSHOT.
• feature/xxx, and also bugfix/yyy, hotfix/zzz - branches for a specific task development. The version for such build

You might see that we need three components to compose the version:

• previous version
• current tags
• current branch name

The main setting of sbt-git-flow-version is versionPolicy which has type Seq[(BranchMatcher => VersionCalculator)]. So it tries to find matching rule for a branch and calculate a version.

What is a BranchMatcher? It’s a function String => Option[Matching] where matching is a case class containing branch name and some additional optional extracted string. There are several predefined branch matchers:

• exact(name: String) - branch name is equals to name, extraction is empty.
• prefix(prefix: String) - branch name starts with prefix. The part after prefix is extraction.
• prefixes(prefixes: String*) - same as prefix but supports a number of prefixes.
• regex(r: String) - branch name matches regular expression r. If the expression contains groups, the first group will be returned as extraction.
• any - matches any branch (might be used to define default behaviour).

The VersionCalculator converts previous version, current version, and matching either to the version number or error message. The predefined version calculators are:

• currentTag - take a version from a current tag. If there are several current tags it will take the one with a maximal version.
• nextMajor, nextMinor, nextBuild, nextN - increment major, minor, build or n-th number of a last version. The version is snapshot by default.
• matching - take a version from matching returned by BranchMatcher. The version is snapshot by default.
• lastVersion - previous version. Version value is taken from last tag or initialVersion setting. The version is not snapshot by default.
• lastVersionWithMatching - takes last version and append matching returned by BranchMatcher. By default new version is snapshot.
• unknownVersion - fails with unknown version message.

The default policy is defined as:

Seq(
  exact("master") -> currentTag(),
  exact("develop") -> nextMinor(),
  prefix("release/") -> matching(),
  prefixes("feature/", "bugfix/", "hotfix/") -> lastVersionWithMatching(),
  any -> unknownVersion
)

What literally means following:

• If branch name is “master” then the branch name is a current commit tag
• If branch name is “develop” then the branch name is a next minor version. E.g. if last version was 1.4.2, the current version is 1.5.0-SNAPSHOT.
• If the branch name starts with “release/” then the version is taken from the branch name. E.g. for the branch release/2.12.85 the version is 2.12.85-SNAPSHOT.
• For the branches started with “feature/”, “bugfix/”, and “hotfix/” the version is a combination of the last version and matching. E.g. for the branch feature/123-new-ui and the prevous version “1.0.1” the current version is 1.0.1-123-new-ui-SNAPSHOT.
• Finally, if the branch name doesn’t follow any of these rules, the build fails, because version is unknown.

You can define your own rules in you build.sbt in the following way:

import sbtgitflowversion.BranchMatcher._
import sbtgitflowversion.VersionCalculator._

versionPolicy := (exact("big-release") -> next-major()) +: versionPolicy.value

This will set the next major version for the “big-release” branch.

Current verion of the plugin is 0.1. So, to add to your project/plugins.sbt the line:

addSbtPlugin("me.limansky" % "sbt-git-flow-version" % "0.1")

The main goal of this release is to make BeanConverter more intelligent. Previously, it required you to have the same type for the corresponding fields in a bean and a product. If there are Java number classes in your beans, it’s possible you don’t want to use it in your Scala code. Instead, you would like to use Options, or you may know that these values are never null.

Now BeanConverter can do these kinds of transformations for you.

JavaTypeMapper type class was introduced to acheive that. It provides two-way conversions for the following cases:

• Java number class to Scala type. E.g. Integer to Int, or java.math.BigDecimal to scala.math.BigDecimal. If Java value is null it throws NullPointerException.
• A class T to an Option[T]. Wraps nullable to Option.
• A class T for which an instance of JavaTypeMapper to class U is available to an Option[U]. For example it is used to convert Integer to Option[Int].
• HList of the elements which can be mapped with JavaTypeMappers, to HList of mapped values.

If you want to have a previous behavior from BeanConverter use StrictBeanConverter class.

So, quite often it is easier to have a separate model in your Scala code, and converters between Java model classes and Scala ones.

BeanPurée is a library that helps you to automate this process. And it helps you to do even more, because it’s a bridge from JavaBeans to shapeless.

Let’s take this Java class as an example:

public class Dog {
    private String name;
    private int age;
    private boolean chaseCats;

    public String getName() { return name; }
    public void setName(String name) { this.name = name; }

    public int getAge() { return age; }
    public void setAge(int age) { this.age = age; }

    public boolean isChaseCats() { return chaseCats; }
    public void setChaseCats(boolean chaseCats) { this.chaseCats = chaseCats; }

    public String toString() {
        return "Dog " + name + ", " + age +
            (chaseCats ? " is looking for cats" : " is sleeping");
    }
}

BeanPurée provides BeanGeneric class, which has the same function with shapeless’s Generic:

scala> import me.limansky.beanpuree._
import me.limansky.beanpuree._

scala> val gen = BeanGeneric[Dog]
gen: me.limansky.beanpuree.BeanGeneric[Dog]{type Repr = shapeless.::[String,shapeless.::[Int,shapeless.::[Boolean,shapeless.HNil]]]} = $anon$1@56f5a8b7

We just get a BeanGeneric instance with representation type String :: Int :: Boolean :: HNil. Internally, BeanGeneric uses the getters order to build the Repr type. Let’s try to use it:

scala> val fima = gen.from("Fima" :: 12 :: false :: HNil)
fima: Dog = Dog Fima, 12 is sleeping

scala> fima.setChaseCats(true)

scala> gen.to(fima)
res3: gen.Repr = Fima :: 12 :: true :: HNi

So far, so good, let’s combine it with shapeless:

scala> case class ScalaDog(name: String, age: Int, chaseCats: Boolean)
defined class ScalaDog

scala> val sgen = Generic[ScalaDog]
sgen: shapeless.Generic[ScalaDog]{type Repr = shapeless.::[String,shapeless.::[Int,shapeless.::[Boolean,shapeless.HNil]]]} = anon$macro$8$1@45e06950

scala> sgen.from(gen.to(fima))
res4: ScalaDog = ScalaDog(Fima,12,true)

Since the shape of Dog and ScalaDog is the same we can convert from one class to another using a combination of Generic and BeanGeneric.

Just as shapeless provides LabelledGeneric with field names information in the Repr type, BeanPurée provides LabelledBeanGeneric, which adds property names to the generic representation.

scala> val lgen = LabelledBeanGeneric[Dog]
lgen: me.limansky.beanpuree.LabelledBeanGeneric[Dog]{type Repr = shapeless.::[String with shapeless.labelled.KeyTag[Symbol with shapeless.tag.Tagged[String("name")],String],shapeless.::[Int with shapeless.labelled.KeyTag[Symbol with shapeless.tag.Tagged[String("age")],Int],shapeless.::[Boolean with shapeless.labelled.KeyTag[Symbol with shapeless.tag.Tagged[String("chaseCats")],Boolean],shapeless.HNil]]]} = me.limansky.beanpuree.LabelledBeanGeneric$$anon$1@412d56b4

scala> lgen.from('name ->> "Rex" :: 'age ->> 5 :: 'chaseCats ->> true :: HNil)
res7: Dog = Dog Rex, 5 is looking for cats

Having this stuff allows me to implement a more intelligent (but not too much) converter between case classes and beans. This class is called BeanConverter. It doesn’t rely on a definition order of properties . Instead, it uses names.

scala> case class ScalaDog(name: String, chaseCats: Boolean, age: Int)
defined class ScalaDog

scala> val conv = BeanConverter[Dog, ScalaDog]
conv: me.limansky.beanpuree.BeanConverter[Dog,ScalaDog] = me.limansky.beanpuree.BeanConverter$$anon$1@5dd7b913

scala> conv.productToBean(ScalaDog("Lassie", false, 5))
res0: Dog = Dog Lassie, 5 is sleeping

That’s all the features of the release 0.1, which is available in the Sonatype Maven repository. I have several ideas for the next releases, e.g automatic Java types to Scala types conversion, and partial converters.

val query = StatementGenerator[Sale].insert(tableName)
val statement = connection.prepareStatement(query)
SqlSaver[Sale](statement, 1)(sale)
statement.execute()

Let’s try to implement it with shapeless.

First, let’s define our type class for statement generators:

trait StatementGenerator[A] {
  def select(table: String): String
  def insert(table: String): String
}

Then we can create a companion object with summoner function and implementation for case classes. Since we need not only values, but also field names, we need to use LabelledGeneric class instead of Generic.

object StatementGenerator {
  def apply[A](implicit sg: StatementGenerator[A]): StatementGenerator[A] = sg

  def genericGenerator[A, R](implicit
    gen: LabelledGeneric.Aux[A, R]
  ): StatementGenerator[A] = new StatementGenerator[A] {
    override def select(table: String): String = ???
    override def insert(table: String): String = ???
  }
}

Ok, we have an instance of LabelledGeneric for type A which can convert an instance of type A to HList R. But we don’t have an A instance, because we don’t need values. All we need are the field names. Shapeless contains package ops which provides utilities for different cases. We need to get keys of the key-value records. The necessary class called Keys is available in package ops.record. It takes an HList of records and provides an HList of keys. The next thing we need to do is to materialize HList of keys into a Scala List of Symbols (because key in our case is Symbol). The utility class we need is called hlist.ToList. We also have to set the constraints for the types we use: a type passed to Keys shall be an HList, as well as a type passed to ToList. Let’s code:

object StatementGenerator {
  def apply[A](implicit sg: StatementGenerator[A]): StatementGenerator[A] = sg

  def genericGenerator[A, R <: HList, K <: HList](implicit
    gen: LabelledGeneric.Aux[A, R],
    keys: record.Keys.Aux[R, K],
    ktl: hlist.ToList[K, Symbol]
  ): StatementGenerator[A] = new StatementGenerator[A] {
    override def select(table: String): String = ???
    override def insert(table: String): String = ???
  }
}

Once we have all the required components we can implement the select and insert methods:

override def select(table: String): String = {
  val fields = keys().toList.map(_.name).mkString(",")
  s"SELECT $fields FROM $table"
}

override def insert(table: String): String = {
  val fieldNames = keys().toList.map(_.name)
  val fields = fieldNames.mkString(",")
  val placeholders = List.fill(fieldNames.size)("?").mkString(",")
  s"INSERT INTO $table ($fields) VALUES($placeholders)"
}

This code is quite straightforward and it works for most cases. But it doesn’t cover all the features of SqlSaver. In the last post we added the ability to save nested case classes. So, we need to recursively handle all of the fields and make a flat list of primitive ones. E.g. if we have classes A(a: String, b: Int) and B(c: String, d: A, e: Int) we should get c :: a :: b :: e :: Nil.

I think it’s better to create a separate type class FieldLister, which will provide a list of fields. Let’s start with our type class:

trait FieldLister[A] {
  val list: List[String]
}

We want to create instances of FieldLister for any class, so we need LabelledGeneric to convert a class to HList:

object FieldLister {
  def genericLister[A, R](implicit
    gen: LabelledGeneric.Aux[A, R],
    lister: Lazy[FieldLister[R]]
  ): FieldLister[A] = new FieldLister[A] {
    override val list = lister.value.list
  }

You might notice, that we don’t need the value of LabelledGeneric. But we need it on the type level, to link types A and R, because type R depends on type A.

Next, we can create instances for HList. It’s obvious that the result list for HNil is Nil:

implicit val hnilLister: FieldLister[HNil] = new FieldLister[HNil] {
  override val list = Nil
}

The instance for a non-empty list is more tricky. We need to separate the primitive types from the nested classes. For the nested classes the implementation is quite simple. We obtain instances for the tail and head and concatenating the result lists:

implicit def hconsLister[K, H, T <: HList](implicit
  hLister: Lazy[FieldLister[H]],
  tLister: FieldLister[T]
): FieldLister[FieldType[K, H] :: T] = new FieldLister[FieldType[K, H] :: T] = {
  override val list = hLister.value.list ++ tLister.list
}

Let’s take a closer look at this function. To understand what’s going on we need to understand what the LabelledGeneric produces. We can check it in REPL:

scala> import shapeless._
import shapeless._

scala> case class Test(first: String, second: Int)
defined class Test

scala> LabelledGeneric[Test]
res0: LabelledGeneric[Test]{
  type Repr = String with KeyTag[Symbol with Tagged[String("first")],String] ::
              Int with KeyTag[Symbol with Tagged[String("second")],Int] ::
              HNil
} =
LabelledGeneric$$anon$1@1b09215f

I rewrote the result type in the infix form and removed package names for readability. What is important here is that the Repr type is not just String :: Int :: HNil, but each type element contains additional type level information.

If we check the shapeless sources, we find that FieldType is just a type alias:

  type FieldType[K, +V] = V with KeyTag[K, V]

That’s exactly what we saw inside Repr. With this knowledge we can rewrite Repr type as:

LabelledGeneric[Test]{
  type Repr = FieldType[Symbol with Tagged[String("first")],String] ::
              FieldType[Symbol with Tagged[String("second")],Int] ::
              HNil
}

And this is the reason we need to define the result type of hconsLister as FieldLister[FieldType[K, H] :: T]. On the value level we just need to concatenate the lists produced for the head and for the tail of the HList.

At this point our code can work with case classes and HLists of elements for which we have instances of FieldLister, i.e. the other HLists and case classes. But what about the primitive types? If we have a head element of HList which does not have an instance of FieldLister, we need to get this field name and set it as a head element of the result list. We need to somehow get the instance of type K on the value level to get the field name. Shapeless provides type class Witness for this purpose. With all of these blocks we can build our function:

implicit def primitiveFieldLister[K <: Symbol, H, T <: HList](implicit
  witness: Witness.Aux[K],
  tLister: FieldLister[T]
): FieldLister[FieldType[K, H] :: T] = new FieldLister[FieldType[K, H] ::T] {
  override val list = witness.value.name :: tLister.list
}

Even though it looks nice, we’ve got a new kind of problem here. Our implicits are ambiguous. Both hconsLister and primitiveFieldLister can be applied to HList. The Scala compiler cannot choose which one is more applicable (even though one of these declarations requires an instance of FieldLister[H], both of the instances have the same weight). So, the compiler requires that you avoid conflicts in the implicit resolution. To manage the implicit resolution order we can use “Low priority” pattern. The idea is to move the implicits with lower precedence to the parent class. Once the compiler can find an implicit instance in the child class it will use it (it will not search all possible implicits in the class parents). But if it is not able to find an implicit in the inherited class, it will search in the parent classes. So we can rewrite it in the following way:

trait FieldListerLowPriority {
  implicit def primitiveFieldLister[K <: Symbol, H, T <: HList](implicit
    witness: Witness.Aux[K],
    tLister: FieldLister[T]
  ): FieldLister[FieldType[K, H] :: T] = new FieldLister[FieldType[K, H] ::T] {
    override val list = witness.value.name :: tLister.list
  }
}

object FieldLister extends FieldListerLowPriority {
  // all other instances are here
}

Now, when we have the FieldLister we can easily implement StatementGenerator. All we need to do is to wrap the FieldLister result into the SQL statements:

object StatementGenerator {
  implicit def genericGenerator[A](implicit
    fieldLister: FieldLister[A]
  ): StatementGenerator[A] = new StatementGenerator[A] {
    override def select(table: String): String = {
      val fields = fieldLister.list.mkString(",")
      s"SELECT $fields FROM $table"
    }

    override def insert(table: String) = {
      val fieldNames = fieldLister.list
      val fields = fieldNames.mkString(",")
      val placeholders = List.fill(fieldNames.size)("?").mkString(",")
      s"INSERT INTO $table ($fields) VALUES ($placeholders)"
    }
  }
}

And that’s all folks.

Fortunately the patch is not too big and I adopted it for the ESR version. Here is it:

diff --git a/dom/base/nsGlobalWindow.h b/dom/base/nsGlobalWindow.h
--- a/dom/base/nsGlobalWindow.h
+++ b/dom/base/nsGlobalWindow.h
@@ -473,7 +473,7 @@
     FullscreenReason aReason, bool aIsFullscreen,
     mozilla::gfx::VRHMDInfo *aHMD = nullptr) override final;
   virtual void FinishFullscreenChange(bool aIsFullscreen) override final;
-  void SetWidgetFullscreen(FullscreenReason aReason, bool aIsFullscreen,
+  bool SetWidgetFullscreen(FullscreenReason aReason, bool aIsFullscreen,
                            nsIWidget* aWidget, nsIScreen* aScreen);
   bool FullScreen() const;

diff --git a/dom/base/nsGlobalWindow.cpp b/dom/base/nsGlobalWindow.cpp
--- a/dom/base/nsGlobalWindow.cpp.orig
+++ b/dom/base/nsGlobalWindow.cpp	
@@ -5905,8 +5905,12 @@
       mWindow->mFullScreen = mFullscreen;
     }
     // Toggle the fullscreen state on the widget
-    mWindow->SetWidgetFullscreen(nsPIDOMWindow::eForFullscreenAPI,
-                                 mFullscreen, mWidget, mScreen);
+    if (!mWindow->SetWidgetFullscreen(nsPIDOMWindow::eForFullscreenAPI,
+                                      mFullscreen, mWidget, mScreen)) {
+      // Fail to setup the widget, call FinishFullscreenChange to
+      // complete fullscreen change directly.
+      mWindow->FinishFullscreenChange(mFullscreen);
+    }
     // Set observer for the next content paint.
     nsCOMPtr<nsIObserver> observer = new Observer(this);
     nsCOMPtr<nsIObserverService> obs = mozilla::services::GetObserverService();
@@ -5985,14 +5989,14 @@
   }
   nsCOMPtr<nsIScreen> screen = aHMD ? aHMD->GetScreen() : nullptr;
   if (!performTransition) {
-    aWindow->SetWidgetFullscreen(aReason, aFullscreen, widget, screen);
+    return aWindow->SetWidgetFullscreen(aReason, aFullscreen, widget, screen);
   } else {
     nsCOMPtr<nsIRunnable> task =
       new FullscreenTransitionTask(duration, aWindow, aFullscreen,
                                    widget, screen, transitionData);
     task->Run();
+    return true;
   }
-  return true;
 }
 
 nsresult
@@ -6096,7 +6100,7 @@
   return NS_OK;
 }
 
-void
+bool
 nsGlobalWindow::SetWidgetFullscreen(FullscreenReason aReason, bool aIsFullscreen,
                                     nsIWidget* aWidget, nsIScreen* aScreen)
 {
@@ -6108,13 +6112,12 @@
   if (nsCOMPtr<nsIPresShell> presShell = mDocShell->GetPresShell()) {
     presShell->SetIsInFullscreenChange(true);
   }
-  if (aReason == nsPIDOMWindow::eForFullscreenMode) {
+  nsresult rv = aReason == nsPIDOMWindow::eForFullscreenMode ?
     // If we enter fullscreen for fullscreen mode, we want
     // the native system behavior.
-    aWidget->MakeFullScreenWithNativeTransition(aIsFullscreen, aScreen);
-  } else {
+    aWidget->MakeFullScreenWithNativeTransition(aIsFullscreen, aScreen) :
     aWidget->MakeFullScreen(aIsFullscreen, aScreen);
-  }
+  return NS_SUCCEEDED(rv);
 }
 
 /* virtual */ void
diff --git a/widget/nsIWidget.h b/widget/nsIWidget.h
--- a/widget/nsIWidget.h
+++ b/widget/nsIWidget.h
@@ -1137,16 +1137,20 @@ class nsIWidget : public nsISupports {
                                              nsIRunnable* aCallback) = 0;
 
     /**
      * Put the toplevel window into or out of fullscreen mode.
      * If aTargetScreen is given, attempt to go fullscreen on that screen,
      * if possible.  (If not, it behaves as if aTargetScreen is null.)
      * If !aFullScreen, aTargetScreen is ignored.
      * aTargetScreen support is currently only implemented on Windows.
+     *
+     * @return NS_OK if the widget is setup properly for fullscreen and
+     * FullscreenChanged callback has been or will be called. If other
+     * value is returned, the caller should continue the change itself.
      */
     NS_IMETHOD MakeFullScreen(bool aFullScreen, nsIScreen* aTargetScreen = nullptr) = 0;
 
     /**
      * Same as MakeFullScreen, except that, on systems which natively
      * support fullscreen transition, calling this method explicitly
      * requests that behavior.
      * It is currently only supported on OS X 10.7+.
diff --git a/widget/gtk/mozgtk/mozgtk.c b/widget/gtk/mozgtk/mozgtk.c
--- a/widget/gtk/mozgtk/mozgtk.c
+++ b/widget/gtk/mozgtk/mozgtk.c
@@ -122,16 +122,17 @@ STUB(gdk_x11_display_get_user_time)
 STUB(gdk_x11_display_get_xdisplay)
 STUB(gdk_x11_get_default_root_xwindow)
 STUB(gdk_x11_get_default_xdisplay)
 STUB(gdk_x11_get_server_time)
 STUB(gdk_x11_get_xatom_by_name)
 STUB(gdk_x11_get_xatom_by_name_for_display)
 STUB(gdk_x11_lookup_xdisplay)
 STUB(gdk_x11_screen_get_xscreen)
+STUB(gdk_x11_screen_supports_net_wm_hint)
 STUB(gdk_x11_visual_get_xvisual)
 STUB(gdk_x11_window_foreign_new_for_display)
 STUB(gdk_x11_window_lookup_for_display)
 STUB(gdk_x11_window_set_user_time)
 STUB(gdk_x11_xatom_to_atom)
 STUB(gtk_accel_label_new)
 STUB(gtk_alignment_get_type)
 STUB(gtk_alignment_new)
diff --git a/widget/gtk/nsWindow.cpp b/widget/gtk/nsWindow.cpp
--- a/widget/gtk/nsWindow.cpp
+++ b/widget/gtk/nsWindow.cpp
@@ -4972,22 +4972,39 @@ nsWindow::PerformFullscreenTransition(Fu
     auto transitionData = new FullscreenTransitionData(aStage, aDuration,
                                                        aCallback, data);
     g_timeout_add_full(G_PRIORITY_HIGH,
                        FullscreenTransitionData::sInterval,
                        FullscreenTransitionData::TimeoutCallback,
                        transitionData, nullptr);
 }
 
+static bool
+IsFullscreenSupported(GtkWidget* aShell)
+{
+#ifdef MOZ_X11
+    GdkScreen* screen = gtk_widget_get_screen(aShell);
+    GdkAtom atom = gdk_atom_intern("_NET_WM_STATE_FULLSCREEN", FALSE);
+    if (!gdk_x11_screen_supports_net_wm_hint(screen, atom)) {
+        return false;
+    }
+#endif
+    return true;
+}
+
 NS_IMETHODIMP
 nsWindow::MakeFullScreen(bool aFullScreen, nsIScreen* aTargetScreen)
 {
     LOG(("nsWindow::MakeFullScreen [%p] aFullScreen %d\n",
          (void *)this, aFullScreen));
 
+    if (!IsFullscreenSupported(mShell)) {
+        return NS_ERROR_NOT_AVAILABLE;
+    }
+
     if (aFullScreen) {
         if (mSizeMode != nsSizeMode_Fullscreen)
             mLastSizeMode = mSizeMode;
 
         mSizeMode = nsSizeMode_Fullscreen;
         gtk_window_fullscreen(GTK_WINDOW(mShell));
     }
     else {

If you use Gentoo you can just put the patch in /etc/portage/patches/www-client/firefox/firefox-45.7.0/patch.diff file and reemerge Firefox.

Unfortunately, Paginate provides only first/previous/current/next/last functionality. It’s quite common to have only “Older posts” and “Newer posts” buttons for blogs, but I’d like to have a list of all pages in the Bootstrap pagination component. So, it’s time to write some Haskell code (of course you need to write code to add the standard Paginate, but I’m going to write a little bit more).

Generating paginated pages

Let’s set up basic Paginate and then extend it. If you are already familiar with Paginate, you can skip this section.

The data type Paginate holds mapping from page numbers to Identifiers. The buildPaginateWith function is used to create Paginate instances. This function has three parameters:

• grouper – a function to group a list of Identifiers into chunks
• pattern – a Pattern instance to get required items
• makeId – a function to map page numbers to Identifiers

Let start with makeId as the simplest one:

postsPageId :: PageNumber -> Identifier
postsPageId n = fromFilePath $ if (n == 1) then "index.html" else show n ++ "/index.html"

Pretty straightforward, right? It creates an Identifier from the file path. If it’s the first page, the path is just “index.html”, otherwise it should take “index.html” file from the folder named with a page number, e.g. “2/index.html”.

The grouper has the following signature:

postsGrouper :: MonadMetadata m => [Identifier] -> m [[Identifier]]

Hakyll provides the paginateEvery function which takes a list and groups it into chunks of a specified number of elements. Another useful function is sortRecentFirst, which sorts a list of Identifiers. So, we need to sort a list of identifiers and then paginate it. To do that, we need to lift the paginateEvery function to the MonadMetadata monad.

import Control.Monad (liftM)

postsGrouper :: MonadMetadata m => [Identifier] -> m [[Identifier]]
postsGrouper = liftM (paginateEvery 10) . sortRecentFirst 

Now we can build a Paginate instance:

main = checkArgs <$> getArgs >>=
        \(postsPattern, conf, args) -> withArgs args $ hakyllWith conf $ do

    paginate <- buildPaginateWith postsGrouper postsPattern postsPageId

In a simple case postsPattern can be just a string "posts/*", but I use different configurations depending on the command line parameters (see Draft posts with Hakyll post).

Once we obtain a Paginate instance we can generate content using the paginateRules function. This function takes an instance of Paginate as a parameter and a function with the following signature PageNumber -> Pattern -> Rules() as a second parameter.

    paginateRules paginate $ \page pattern -> do
        route idRoute
        compile $ do
            posts <- recentFirst =<< loadAllSnapshots pattern "content"
            let indexCtx =
                    constField "title" (if page == 1 then "Latest blog posts"
                                                     else "Blog posts, page " ++ show page) <>
                    listField "posts" (previewCtx tags) (return posts) <>
                    paginateContextPlus paginate page <>
                    mainCtx tags postsPattern

            makeItem ""
                >>= applyAsTemplate indexCtx
                >>= loadAndApplyTemplate "templates/posts-preview-list.html" indexCtx
                >>= loadAndApplyTemplate "templates/page-right-column.html" indexCtx
                >>= loadAndApplyTemplate "templates/default.html" indexCtx
                >>= relativizeUrls

Hakyll has the paginateContext function which returns a context with a number of fields for the specific page. As I said before, this is not enough for me, so I’m using paginateContextPlus, which is defined in the next section.

Extending paginate context

To create the paginator I need a list of all the pages, and a current page. Since it is not possible to perform an equality check inside the template, I decided to split the list of pages into two parts: pages before the current one, and pages after it. Let’s write a function which will create a context with these fields:

import qualified Data.Map as M

paginateContextPlus :: Paginate -> PageNumber -> Context a
paginateContextPlus pag currentPage = paginateContext pag currentPage <> mconcat
    [ listField "pagesBefore" linkCtx $ wrapPages pagesBefore
    , listField "pagesAfter"  linkCtx $ wrapPages pagesAfter
    ]
    where

I included paginateContext into the result of this function. Since we need a lists of pages, we need to use the listField function to create contexts. We need to create nested contexts for the list elements:

        linkCtx :: Context (String, String)
        linkCtx = field "pageNum" (return . fst . itemBody) <>
                  field "pageUrl" (return . snd . itemBody)

The next step is to get the information about each page except the current one and split the list of the pages into two parts:

        pages = [pageInfo n | n <- [1..lastPage], n /= currentPage]
        lastPage = M.size . paginateMap $ pag
        pageInfo n = (n, paginateMakeId pag n)

        (pagesBefore, pagesAfter) = span ((< currentPage) . fst) pages

And the last required part is a wrapPages function, which converts [(PageNumber, Identifier)] into Compiler [Item (String, String)]. Let’s start with a helper function to convert a single list item into Compiler (Item (String, String)).

        makeInfoItem :: (PageNumber, Identifier) -> Compiler (Item (String, String))
        makeInfoItem (n, i) = getRoute i >>= \mbR -> case mbR of
            Just r  -> makeItem (show n, toUrl r)
            Nothing -> fail $ "No URL for page: " ++ show n

Now, we can map a list with makeInfoItem:

        wrapPages :: [(PageNumber, Identifier)] -> Compiler [Item (String, String)]
        wrapPages = sequence . map makeInfoItem

Since Compiler is a monad, we can convert a list of Compilers to the Compiler of the list with the sequence function.

Template

Now, when we have all the required variables in the context, it is simple to add the paginator to the template:

<nav aria-label="Page navigation">
  <ul class="pagination">
    $if(previousPageNum)$
    <li>
    $else$
    <li class="disabled">
    $endif$
    $if(previousPageNum)$
      <a href="$previousPageUrl$">
    $else$
      <a href="#">
    $endif$
        <span aria-hidden="true">&laquo;</span>
      </a>
    </li>
    $for(pagesBefore)$
    <li><a href="$pageUrl$">$pageNum$</a></li>
    $endfor$
    <li class="active">
      <a href="#">$currentPageNum$<span class="sr-only">current</span></a>
    </li>
    $for(pagesAfter)$
    <li><a href="$pageUrl$">$pageNum$</a></li>
    $endfor$
    $if(nextPageNum)$
    <li>
    $else$
    <li class="disabled">
    $endif$
    $if(nextPageNum)$
      <a href="$nextPageUrl$">
    $else$
      <a href="#">
    $endif$
        <span aria-hidden="true">&raquo;</span>
      </a>
    </li>
  </ui>
</nav>

Hakyll requires you to check if the previous/next page variables are defined, because they are not defined on the first/last page.

And that’s all.

First of all, it doesn’t work properly with nested classes. Let’s start with a test:

case class SaleRecord(id: Int, sale: Sale, seller: String)

it should "save nested case classes" in {
  val date = LocalDateTime.now
  SqlSaver[SaleRecord].save(stm, 6)(
    SaleRecord(1, Sale("bar", date, 42), "Shop")
  ) should equal(11)

  verify(stm).setInt(6, 1)
  verify(stm).setString(7, "bar")
  verify(stm).setTimestamp(8, Timestamp.valueOf(date))
  verify(stm).setBigDecimal(9, java.math.BigDecimal.valueOf(42))
  verify(stm).setString(10, "Shop")
}

Unfortunately it doesn’t compile:

[error] SqlSaverTest.scala:38: diverging implicit expansion for type SqlSaver[LocalDateTime :: BigDecimal :: HNil]
[error] starting with method hlistSaver in object SqlSaver
[error]    SqlSaver[SaleRecord].save(stm, 6)(
[error]            ^

Note: here and later I rewrote HLists into the infix form, for readability.

That’s strange. We know that SqlSaver for Sale can be instantiated, because Sale contains only fields of supported types. Maybe shapeless cannot construct Generic for our nested classes? If we try to do it in REPL we get the following result:

Generic[SaleRecord]{type Repr = Int :: Sale :: String :: HNil }

But if we try to evaluate SqlSaver[Int :: Sale :: String :: HNil] we get an error. The problem we are faced with is related to how Scala implicit resolution works. This topic is described in “The Type Astronaut’s Guide to Shapeless”. The main idea is that the Scala compiler tries to avoid infinite loops during implicit resolution. To do that, it has several heuristics. One of them is to stop searching if it meets the same step twice. Another one is to stop if the complexity of type parameters is increasing for the type constructor it met before. In shapeless one of the type constructors is ::[H, T] – the constructor of HList. In our case we get a more complex HList for Sale than for SaleRecord, so it cannot find an implicit instance of SqlSaver[Sale] and doesn’t compile. Fortunately shapeless has special type Lazy to solve this problem (else shapeless would be a quite useless thing). Let’s fix the last error case:

implicit def hlistSaver[H, T <: HList](implicit
     hSaver: Lazy[SqlSaver[H]],
     tSaver: SqlSaver[T]
  ): SqlSaver[H :: T] = createSaver {
    case (h :: t, stm, idx) =>
      hSaver.value.save(stm, idx)(h)
      tSaver.save(stm, idx + 1)(t)
  }

Once we wrapped the hSaver in Lazy it prevents the compiler from being too clever, and postpones the implicit parameters evaluation to runtime. Now the SqlSaver for HList works properly. We can fix the genericSaver in the same way, wrapping saver into Lazy:

implicit def genericSaver[A, R](implicit
     gen: Generic.Aux[A, R],
     saver: Lazy[SqlSaver[R]]
  ): SqlSaver[A] =
    createSaver((v, stm, idx) => saver.value.save(stm, idx)(gen.to(v)))

Now the test compiles successfully but fails on runtime with “9 did not equal 11” message. What happened? The current implementation of HList saver assumes that the head saver takes only one element. This worked for primitive types, but of course doesn’t work for classes. To fix that we need to use the next index returned by hSaver:

implicit def hlistSaver[H, T <: HList](implicit
     hSaver: Lazy[SqlSaver[H]],
     tSaver: SqlSaver[T]
  ): SqlSaver[H :: T] = createSaver {
    case (h :: t, stm, idx) =>
      val next = hSaver.value.save(stm, idx)(h)
      tSaver.save(stm, next)(t)
  }

Now it works fine for nested classes.