I never considered myself as web frontend developer, cause I usually prefer doing more system stuff, but time over time I do it, and sometimes I have to target old browsers, and so I have to test using these browsers. While there are services like SauceLabs and BrowserStack which offer you cloud backed web browser testing, often testing and debugging using these services are slow. They are fine as quality gate used in CI, but using them continuously slow downs development. Running tests and debugging in browser locally is much faster.

So let’s start with Firefox, cause it’s the easiest case. All Firefox releases are published in a archive. But just installing every single version that you need to support isn’t going to work for you on Linux (at least for me). Cause all these versions of browsers using same paths for storing user profile data. You obviously can try to separate them by using different environment variables for profiles and other settings. Also, you probably would have to disable remote interface via -no-remote CLI option, which disables listening socket that accepts commands. This used as way to speed up browser launching, since browser stays loaded even when you close all pages and when you click to open something it receives remote command. But since we are going to run multiple versions they would bind to same socket which would cause a conflict. There is also number of other issues as well.

So, is there is any better way ? Yeah, let’s use lightweight containers for this. I often use bwrap aka bubblewrap for these kind of issues. Here’s for example my launcher for Firefox 38:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#!/bin/sh
/usr/bin/bwrap \
    --ro-bind /bin /bin \
    --ro-bind /lib /lib \
    --ro-bind /lib64 /lib64 \
    --ro-bind /usr/bin /usr/bin \
    --ro-bind /usr/lib /usr/lib \
    --ro-bind /usr/lib64 /usr/lib64 \
    --ro-bind /usr/libexec /usr/libexec \
    --ro-bind /usr/share /usr/share \
    --ro-bind /etc /etc \
    --tmpfs /home \
    --tmpfs /run \
    --tmpfs /opt \
    --tmpfs /tmp \
    --bind /var/tmp /var/tmp \
    --dev-bind /dev /dev \
    --proc /proc \
    --bind /sys /sys \
    --tmpfs $HOME \
    --ro-bind $HOME/.Xauthority $HOME/.Xauthority \
    --bind $HOME/.nv/ $HOME/.nv/ \
    --ro-bind $HOME/.nvidia-settings-rc  $HOME/.nvidia-settings-rc \
    --ro-bind /tmp/.X11-unix/ /tmp/.X11-unix/ \
    --bind $HOME/.config/pulse/ $HOME/.config/pulse/ \
    --bind /run/user/ /run/user/ \
    --bind $HOME/.local/oldbrowsers/ $HOME/oldbrowsers/ \
    --unshare-all --share-net \
    --chdir $HOME/ \
      "$HOME/oldbrowsers/firefox-38/firefox-bin"

This should be pretty self-explanatory, but I’ll comment on few details. $HOME is mounted as tmpfs, so when bwrap process dies, it will be unmounted and all data that were stored this folder disappears, which is exactly what I wanted for testing. Also, as you can see this isn’t fully isolated container, it shares all system folder with you system, mostly in read only mode, so it takes just a minimal amount of disk space.

With Chrome things get little bit harder, cause there is no official release archive for it. But you should keep remember that Chrome is based on Chromium which is open-source and has public CI with results of a build. But usually you can easily find a super new experimental builds, not an old outdated builds. Luckily someone made a tool that could simplify that. Basically it helps you find correct git commit for particular release of interest and build artifacts. In addition, someone generated list of artifacts for large amount of different versions. And there is another website with simpler UI, where you can get links to official build artifacts, but it has much less of them. And with Chromium you can use same trick with bwrap (in some cases you might require using --no-sandbox options).

Now what about testing in IE 11 and Microsoft Edge ? It’s been surprising for me to discover that Microsoft actually has testing VMs on their website that intended exactly for this purpose absolutely for free. These VMs will expire after 90 days, but you can make snapshot, and use them as long as you want. Moreover, these VMs could be used also for application testing as well, for example you could compile app on a Linux via mingw and test generated executable in these VMs.

Now we left with only one major browser left, Safari. So what about it ? Unfortunately I don’t know any way to run it under Linux, so your only available options is use physical device (Apple device) or use some remote service like macincloud. Well, strictly speaking you can still run it in VM under Linux (but shh, I did told you that).