On Fri, Oct 17, 2008 at 2:37 PM, John Tamplin <[EMAIL PROTECTED]> wrote: > FF1.5/FF2 support -- a number of widely-used Linux distributions still do > not have FF3 available, including many heavily used inside enterprises.
For trunk work, I'm personally not too concerned with this. I think people compiling the trunk and living on the bleeding edge won't mind upgrading their Firefox distributions, although I agree it might be an issue when GWT 2.0 is ready for release. > 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: Probably the easier way to handle this in Windows is to use a VM, that's what we do today. We use Xvfb for Firefox tests, a VMWare XP instance for IE tests, and a laptop or Mac Mini to run the OSX tests. To some extent, this will all go away when OOPHM arrives. Our plan is to run a single WinXP VMWare instance with selenium server which tests Firefox, WebKit, Opera, and IE, since all of the required rendering engines are available under Windows, with the exception of stuff like the iPhone. I'm not sure of the legal issues, but it may be possible to create a pre-configured VMWare player binary that contains a selenium instance capable of being a remote GWT OOPHM test appliance. I advocate the VM approach for other reasons to, since you can't have IE6/IE7/IE8 running side by side in a single WinXP instance, using VMs allows you to test with multiple IE versions. > 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. I hope we can finally retire all native libraries, and SWT code from the GWT devjar distribution because it complicates a number of things: 1) makes it hard for IDE vendors like JetBrains to integrate HM shell directly into their IDE (they are Swing based) 2) Broke HM on Leopard for a long time because of Carbon/SWT changes. 3) requires irritating -XstartOnFirstThread parameter everywhere. 4) Breaks Maven Surefire unit testing classloader 5) makes the gwt-maven plugin/config more complex than it needs to be. If the old SWT based HM is to be maintained, can we package it in a separate jar with a separate launcher so that other embeds of HM can get away with ignoring it? > Removing missing plugin warning when using XPCOM (perhaps by dynamically > injecting tags in hosted.html or splitting hosted.html into > platform-specific bits). You know what would be cool is if the selenium stuff + HM could provision plugins remotely, so one doesn't have to go to all of ones test instance servers and update the plugins whenever they change. I don't know how feasible it would be, but minimally, some way of probing the versions and notifying you which remote test browsers are running old plugins would be useful. I could see a future where perhaps someone updates a devjar containing changes to the wire protocol, but has stale plugins (forgets to upgrade some browser), and then runs into an obscure heisenbug. -Ray > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
