Comment 30 for bug 78538

(In reply to comment #22)
> This above loop isn't quite right. If we have screens 0, 1, and 2, with 1

Err, what was I thinking.. that's obviously wrong, will fix that in a later patch.

> That said, I'm rather puzzled as to how this patch fixes this bug? I can't
> seem to see how it would allow opening windows on multiple screens. I think
> the reporter can work around his problem by running firefox with
> MOZ_NO_REMOTE=1 (or whatever that env var is called) in addition to the
> DISPLAY= magic and set up differing profiles.

$ MOZ_NO_REMOTE=1 DISPLAY=:0.1 firefox

still throws that error. Part of the explanation why that happens in in comment #16. Every new instance of FF will first try to use xremote and if that fails than it goes on and tries to lock the profile. Without my patch, FF can't find a running FF and goes kaboom when it tries to lock the profile because the other instance has it locked already.
And in comment #17 I explained that the patch doesn't fix the bug fully, but only part of it, enough to make FF usable with multiple screens (at least clicking links works from both screens).

Fixing the bug wholly is IMHO very difficult, because it would either require two separate FF instances to lock the profile simultaneously. Or it would require a rewrite of the gtk/x11 UI code to not rely on get_default_screen/display etc. and use the screen/display that the user passes to it through xremote (like: FF running on screen 0, user executes firefox on screen 1, it passes the command and DISPLAY=.1 to the running instance and that makes sure that the new window opens on screen 1).