I'm looking forward to seeing OOPHM and runAsync merged into trunk. I'll take a look at getting the XPCOM plugin to work in FF2/Gecko 1.8 this weekend. I was able to get the Mac version to work in Firefox 2 with relatively few changes, so I hope the same will be true on other platforms.
We may also want to decide if we want to place some or all of the xulrunner SDK in the tools/ directory before the merge to trunk. I think putting the entire SDK would be in the tools/ directory would be much too large, but we may be able to place only the pieces necessary to compile the XPCOM and NPAPI plugins. (I think Gears takes this approach). -Sam On Fri, Oct 17, 2008 at 5:37 PM, John Tamplin <[EMAIL PROTECTED]> wrote: > I think it is time to decide on the criteria for when OOPHM should get > merged to trunk so we can be working down that list. Since we forked 1.6 > and the trunk is available for 2.0 stuff, I think the criteria should be > when developers working from trunk can switch to OOPHM with minimal > disruption. Here are the things I think need to be addressed: > > - FF1.5/FF2 support -- a number of widely-used Linux distributions > still do not have FF3 available, including many heavily used inside > enterprises. > - Testing - existing hosted mode runs in headless by default, but since > we aren't embedding the browser with OOPHM we can't easily do that. On Mac > and Windows that leads to a problem in that the window pops up and steals > focus. Possibilities: > - For Linux, you can run Selenium-RC inside an Xvfb display and > everything works perfectly (arguably better than before). However, I > don't > know how to do something similar on Mac OSX or Windows (at least on > Windows > it seems like it should be possible to emulate all of GDI, but it would > be > tons of work and I am not aware of it being done -- perhaps Wine code > could > be useful). > - Use a SWT-embedded browser as an OOPHM client. The bad part of > this is we are still in the business of distributing native binaries > (besides the plugins) and have 32/64-bit issues, plus we would still be > testing against an old browser on Linux. > - Allow the old SWT-based code to be selected at runtime, which > avoids the OOPHM wire protocol but otherwise has the issues above. > - In general, it only pops up once per test run and you can iconify > it and go on, so maybe it isn't a big deal. > - Swing UI runnable on JDK 1.5 -- the solution I used for adding > close tab buttons turns out to have been added in 1.6, so it needs to be > rewritten using only methods on 1.5. From a bit of research, this is > really > nasty code but a lot of people have done it so it shouldn't be too big a > deal to do. > - Removing missing plugin warning when using XPCOM (perhaps by > dynamically injecting tags in hosted.html or splitting hosted.html into > platform-specific bits). > - Implement whitelist/permissions checking for OOPHM connections. This > probably also means we have a preferences UI for setting this. > - UI mocked parts implemented or removed. > > Here are other to-do items which I think should not be blocking for getting > it into trunk: > > - Chrome plugin > - handle exceptions on field get/set > - more robust dealing with dropped connections > - code refactor to pull out more common code between plugins > > Comments on these or suggestions of other things that should be considered? > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
