Anyhow, I went back through the archives and found the following issues
to be what we have discussed before:

1) The Selection area as described above. If that only affects Mac and
there is a maintainable workaround that should be fine.

There will be the similar scheme to which we use for drowning resizes
elements now.
"drowning resizes elements" ? You mean not have them show up or ?
2) Platform availability - can we get or produce a xulrunner 1.9 binary
for all our supported platforms ? x86_64 bit ? Mac Cocoa/Carbon
Mozilla provide support for following platforms linux x86,win32, Mac
i386(I have cheeked work only on carbon, i haven't checked it on cocoa).
For other platforms(linux x64 and windows x64 we can build XR1.9, it's
much ease than build XR1.8.
Also there exists an bug on win x64, that user can't select more then
677MB of memory when run eclipse x32 and java x32.You can see this
So build of xulrunner for this platform is important.
I actually got some contact me wanting to help out do a Win X64 build for us. Got some docs/links I can send to him or should
we just do it over email ?
3) Updatability - will users (of both jboss tools and JBDS) be able to
update to xulrunner 1.9 via our updatesite  without conflicts to the SWT
integration/hook/hack ?
It should work without any problems.
If we can solve/verify these or at least find acceptable workarounds and
there isn't any other known problems then lets move to XulRunner 1.9
after M3 have been released.
Lets discuss it tomorrow (friday) on the call with Denis and Alexey - but from the sound of it we should move up to xulrunner 1.9
for the M4 release.