WebRunner for Firefox 3.6?

10 May 2011 by Matthew Gertner - Category: Salsita

Having discovered that some recent changes to WebRunner had broken compatibility with Firefox 3.6, I had more or less decided simply to discontinue support for older versions of Firefox. Then I stumbled on the fact that nearly 64% of Firefox users still have version 3.6. I thought a bit harder about it, but I’m still inclined to release future versions of WebRunner for Firefox 4.0+ only.

One practical consideration is that working with older Firefox versions imposes a number of constraints on extension developers. For example, I upgraded to XCode 4 the other day and, while it still has a few bugs and other annoyances, I quite like it. Unfortunately, it seems that I can’t build Firefox 3.6 anymore on my Mac since it requires use of the OS X 10.5 SDK, which is not shipped with XCode 4. I could try copying it over from an older XCode installation, but already I’d be pushed into the kind of hackery that I would just as soon avoid. I depend on having a debug build of Firefox when testing so this is quite a nuisance.

A more general issue is that we will be forced to test all new WebRunner versions not only on three platforms (Mac, Windows and Linux) but also on two Firefox versions. For a small team, this can be a major effort and will take away from the time that we can spend on adding new features, developing great sample apps, writing documentation and the like. It’s true that the new, more aggressive Firefox release schedule is probably going to force us to support multiple versions anyway, but this could be seen as all the more reason to discontinue support for Firefox 3.6.

This is not such a big deal for most extension developers, since they probably aren’t doing many things that require changes between Firefox 3.6 and 4.0. WebRunner, however, is a complex extension that includes a lot of binary code and XPCOM components and uses various APIs that have changed — or, like the extension manager, been completely rewritten — between Firefox 3.6 and 4.0.

I’m interested to know what others think. In the case of WebRunner specifically, is it reasonable to expect users to upgrade to Firefox 4.0 if they want to use it? And have any other extension developers discovered that maintaining support for Firefox 3.6 will be a non-negligible effort? If so, how are you addressing this?


« - »
COMMENTS
  • http://adblockplus.org/ Wladimir Palant

    I think that WebRunner users are more likely to use a current Firefox version. Unfortunately, you don’t have an update URL so you cannot check how many of your users really use Firefox 4.

    Speaking of which, WebRunner’s update story is more of a concern to me. I recently discovered that WebRunner was only marked as compatible with Firefox 4.0 rather than Firefox 4.0.* and an update to Firefox 4.0.1 broke it. I then also discovered that an update was available but automated updates were unavailable. Once the update was installed I noticed that the extension itself was compatible with Firefox 4.0 but the stub webapp wasn’t (max Gecko version 2.0 rather than 2.0.*). And when I fixed this manually I noticed that existing webapps keep the compatibility info that they were created with and have to be changed manually – not great at all. I don’t think that going through all this is something you can ask regular users to do.

  • http://www.salsitasoft.com/ Matthew Gertner

    The issues you mention are bugs that have already been fixed. We pushed out WebRunner rather quickly to respond to the unexpected news that “Prism is now Chromeless”, and a few configuration details slipped through the cracks. The issue of the extension being copied to the profile of each web app is unfortunate but I haven’t figured out a better way of doing it (actually I have some ideas but they will be a bit more involved to implement). In any case, I’ve been waiting for WebRunner to become more stable before making more of a push for users. I think it’s pretty close in its latest incarnation.

    The reason it doesn’t have an updateURL is that I’ve been waiting for about two months for it to get AMO approval.

    Thanks for your comments. I hope you’ll check out the latest version. Please do let me know if you still have problems.

  • http://Website Forward to Future

    Drop all support for outdated & obsolete versions of Firefox. If you continue to support them, it will be like IE6 fiasco all over again and cause plenty of headaches when people don’t upgrade their browsers.

    It’s time to embrace the power and speed of Firefox 4.0 and soon Firefox 5.0 and Firefox 6.0

  • http://adblockplus.org/ Wladimir Palant

    Yes, the wrong maxVersion seems to be fixed. However, I doubt that stub/application.ini files for existing webapps will be updated automatically once Firefox 5 (and the corresponding WebRunner extension) is out. You seem to be using a highly customized XULRunner stub, it should then be possible to read application.ini from the WebRunner instance that created the web app and only keep override.ini in the webapp itself. That should take care of compatibility problems, updating WebRunner in Firefox will automatically change the compatibility range of the web apps. Disadvantage: removing WebRunner in Firefox disables all web apps.

    The WebRunner copies in web apps are tricky. Sharing one extension copy between multiple applications/profiles isn’t impossible but it will cause update problems – Firefox won’t be able to update the extension because its files are in use by web apps. I think that the best solution would be leaving the job of keeping the extension in sync to the webrunner.exe stub. It could check modification time of the “master copy” and compare it with the modification time of the extension in webapp profile. If the former is newer it would copy it over. So an update to WebRunner in the Firefox profile would automatically propagate to the web apps. In Firefox 4 it is also possible to disable automatic updates for individual extensions which would be advisable for WebRunner in web apps (don’t know the details).

    All in all, for extensions that haven’t reached stability (and I think that WebRunner hasn’t yet) it makes little sense to support multiple Firefox versions. Firefox 4 gives you significant advantages, in particular you should be able to get rid of webrunner.dll by using js-ctypes – go for it. This will make supporting future Firefox versions easier, that’s more important than Firefox 3.6. By the time you reach stability and are ready to make a run for the users Firefox 3.6 will be meaningless anyway.

    I’ll write a review on AMO, maybe it helps speeding up the process.

  • http://www.nimbusops.com.au JmulvaneY

    For me, i need to remain on FF 3.6 until the vendor upgrades to v4 which I have no control over. I use Prism on Linux thinclient devices to lauch SaaS webapps. Works great! Hope to use Webrunner soon so please include a 3.x compatible build, at least for a period of time.

  • http://www.salsitasoft.com/ Matthew Gertner

    Thanks again for your input, Wladimir. There is another issue that you don’t mention, which is that Firefox won’t update if its files are being used by WebRunner apps. To solve this and the other issues you bring up, I see two options:

    1) A single Firefox and WebRunner install as you suggest. When Firefox and/or WebRunner are updated, all the apps get updated. The extension would have to hook into the Firefox update process somehow and prompt the user to close all WebRunner apps (probably doable though I haven’t looked into the specifics). The stub could “mirror” the WebRunner extension for each app by updating it when the one in Firefox is upgraded.

    2) Create a new Firefox runtime somewhere. When the first WebRunner app is created, Firefox is copied somewhere (e.g. /Applications/WebRunner/Firefox.app on Mac) and used by WebRunner apps instead of the user’s normal Firefox. WebRunner and any WebRunner enhancement extensions (stay tuned!) could be copied into the bin/extensions directory of the WebRunner runtime so that they are automatically available to all apps.

    The biggest weakness of 1) is the one you point out: if the user uninstalls Firefox or WebRunner, all the apps will break. On the other hand, it is more efficient than 2) since it doesn’t keep an extra copy of Firefox lying around. Also 2) will still require some extension update magic since extensions under the Firefox binary don’t auto-update as far as I know. I think there may be some advantages to keeping another Firefox runtime around, but I haven’t decided which is best. Fodder for another blog post, no doubt.

    Regarding webrunner.dll, presumably we’ll need to keep it even if we move to js-ctypes since we have some fairly intricate C/C++/Objective-C logic. It’s not just a question of calling into a few isolated OS APIs. But anyway I’m pretty much sold on discontinuing Firefox 3.6 support. It certainly makes my life easier.

    Anything you can do to speed up the AMO review process would be much appreciated!

  • http://adblockplus.org/ Wladimir Palant

    Yes, Firefox update is another big issue. However, I don’t see how 2) would solve the problem – you still need to update this second Firefox instance somehow which requires closing *all* web apps using it. Also, this instance will need to be in a user-writable location – that’s not a good security practice on Windows and Linux. Generally, I have the impression that it would be better to keep updates centralized in an application that the user is guaranteed to use frequently (meaning: their main browser). I feel that 2) would open a whole new can of worms that you really don’t want to be opened.

    Did you discuss the issue with somebody at Mozilla, rstrong maybe? After all, it is their problem as well. I think that they have been throwing ideas around on how this situation can be resolved. E.g. it might be possible for their update process to signal all running Firefox and WebRunner processes to make them exit.

  • http://Website Bernd Mueller

    i also agree with Wladimir.
    Firefox 3.x will be insignificant when ff 5,6,7 will be out this year soon.

    So please discontinue ff 3.x support and concentrate on stability, bug fixing, new features, documentation, etc.

    do this favor to yourself ;)

    As Wladimir and you also pointed out and mentioned here in the comments, there a lot of other more important things and work to do to make webrunner even better.

    Anyway, users sitting on 3.x can/should use Prism instead. (we also do)
    So i see no sense in using webrunner with “old” 3.x.

  • http://www.salsitasoft.com/ Matthew Gertner

    Wladimir – fair point about the second Firefox install (although it would be possible to install it with admin privileges using an external installer app). In any case, this should theoretically be fixed already if I understand Bug 314148 correctly. I’m not sure why I am still seeing this problem so I’ll have to analyze further.

    It would still be better to prompt the user to close WebRunner apps rather than forcing a restart, but all in all this does seem like a solvable problem. I’ll do some more testing/analysis and try to coordinate with the Mozilla folks if necessary.

  • http://adblockplus.org/ Wladimir Palant

    Bug 314148 has been resolved as a duplicate of bug 525390. I read through the patch there and it appears to only have fixed a much more narrow problem – preventing the user from starting Firefox while the update is in progress (by locking firefox.exe). It does nothing for a Firefox/WebRunner instance already running in background. However, bug 466778 seems to be the one that’s relevant here, if I understand correctly it avoids the whole problem of locked files by renaming the files rather than removing them (if I remember correctly, this works only on NTFS, not on FAT). Applications using the files can continue running, after a restart they will switch to using new files and the old ones can be deleted.

    So maybe the whole problem is indeed already fixed. Two questions need to be answered:

    1) Can Firefox 4 really be updated even though WebRunner is running? Will restarting WebRunner bring the app directory into a consistent state?

    2) Does locking firefox.exe prevent WebRunner from starting? If not, maybe WebRunner should try to open firefox.exe first and refuse to run if it is locked.

  • http://www.salsitasoft.com/ Matthew Gertner

    I know that I had an issue updating Firefox with WebRunner apps running but perhaps this was with Firefox 3.6. I’ll have to test this to confirm.

  • http://www.cornerstonenw.com Peter Rust

    Matthew,

    We don’t require 3.6 support — 4+ is fine.