With the help of @popey and @oSoMoN, we found that adding mknod to the seccomp policy allows things to work. We then looked at an strace of chromium with the policy change and discovered that chromium is unconditionally and AFAICT needlessly doing mknod()s, getting EPERMs and then doing an open(), which succeeds. Because the default snapd policy disallows mknod, this process is killed in strict mode, thus resulting in the black screen. This is a chromium bug; chromium should not be calling mknod() on an existing file which wouldn’t succeed anyway.
Now, if snapd’s seccomp sandbox sent EPERM instead of kill (see the upcoming https://github.com/snapcore/snapd/pull/3998), then that chromium process wouldn’t be killed and things should just work. Using mknod on character and block devices requires CAP_MKNOD to be able to successfully create devices and apparmor mediates this capability. As a result, we can add a workaround rule to the browser-support policy by adding mknod - |S_IFCHR but with a corresponding audit deny capability mknod, apparmor rule which will make it so that the chromium process won’t be killed on mknod, but it still won’t be able to create character devices. When we set the seccomp policy to EPERM instead of kill, this workaround policy can be removed.
@popey, can you report back with the test instructions I gave on IRC (ping me on IRC if you have trouble).