"drowning resizes elements" ? You mean not have them show up or ?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.
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 should2) Platform availability - can we get or produce a xulrunner 1.9 binary for all our supported platforms ? x86_64 bit ? Mac Cocoa/CarbonMozilla 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 thread(http://www.java-forum.org/ides-und-tools/85846-eclipse-maximal-xmx696m-hoeher-geht-nicht.html) So build of xulrunner for this platform is important.
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.93) 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.