On the video, the detaching operation created a detached window to continue typing in and controlling stuff. This suggests to me that they are using some interprocess communication between firefox (or hopefully firefox modules) and the controlling window.
I haven't gone googling on this yet, so it wouldn't surprise me if the following was already in motion.
But it would be very cool to use dbus for this on linux, and enable any program or script to communicate with a running firefox, to give read/write access to all the firefox goodies and states.
This would e.g. enable me to hack together a bash script to ask firefox what url it is currently displaying, and what the <title> string is, and to format this into a citation footnote and append it to a file -- all triggered by a shortcut key. If I want to edit the footnote file automatically after the addition, I can just make it an option passed to the bash script, and invoke it that way manually instead of by shortcut. (I use this example as I already do this with a combination of bash and xclip running firefox in KDE with a clickable custom citation icon in the systray. I keep adding stuff like wrapping text or utf8-lat1 conversion etc., even wget-ing to make a cache copy and adding a local file:// url reference to it, as an option).
Not to belabor it, but the point is to make the firefox goodies available to other programs and scripts, not just create firefox-internal or plugin enhancements. Python would get an alternative to Tkinter for a lot of GUI and graphics stuff.
I wonder if the firefox commands include a !-like shell invocation escape like vim's : command context.
The video showed, IIRC, a command to make a screenshot .png of a specific web page element. One can imagine one-off scripts to do all kinds of useful stuff. But written in any convenient script or even compiled language -- python, bash, c, perl, whatever can talk to dbus.
With dbus control over firefox appearance and widgets, one could write a cool substitute for the dialog command, with firefox sitting minimized and being made to pop up the dialogs.
Well, maybe all the components will become controllable via dbus or successor once Wayland becomes a common graphics base?
Actually, I think every program ought to be accessible as a whatever-it-does server, for client scripts or programs and not just by piping to stdin and capturing stdout (gotta love that unix way though).