Site-specific Browsers and XULRunner

Lately, I've had a few requests to build site-specific browsers (SSBs). SSBs provide some great advantages for companies that have web applications that simply work better on Firefox.

  1. They can deliver their application to companies that don't use Firefox.
  2. They can reduce support costs because the user can't do anything to their browser that will break the application.
  3. They can ensure that their users are at a specific Firefox level.
  4. They can ensure that their users have any specific plugins or plugin versions needed for their application.

In the past, Mozilla had some technology around this like Prism and Chromeless, but decided that this avenue wasn't worth pursuing. There is currently some work around building a web application runtime that will hopefully make this easier, but in the meantime, I've chosen to build my SSBs using XULRunner.

XULRunner is a runtime provided by Mozilla that allows developers to create rich applications like work just like Firefox and Thunderbird. Lots of companies have used it to build some great applications.

If you're using XULRunner or have thought about XULRunner, you should be aware that Mozilla has plans to terminate the XULRunner build and encourage developers to use Firefox as a runtime. See this discussion on mozilla.dev.platform.

I've done some testing and I don't see this affecting any work I'm doing around SSBs because the "Firefox runtime" should provide the exact same functionality that XULRunner does. In addition, because SSBs do not connect to the external web, they are not updated as often and can safely stay on an older version of XULRunner if necessary.

Do you use any site-specific browsers or other XULRunner applications? Do you think this change by Mozilla will affect you?

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

8 thoughts on “Site-specific Browsers and XULRunner

  1. I have seen multiple users asking for just a simple chromeless window for a website.
    Would it not be possible to create an addon that generates a webapp/manifest for an arbitrary site? (The followup being: If yes, would it also be possible to add rudimentary navigation?)

    • That's a good question. I honestly don't know. In theory, you could actually generate the XUL on the fly and invoke Firefox with -application, but you wouldn't get proxies and things like that.

      I would hope that what you're proposing is on the WebApps RT radar. Chrome provides this feature out of the box (although with no navigation).

  2. What scares many of our corporate customers is the word "Firefox". We've shipped Prism in the past, and a XULRunner replacement more recently, with no complaints - but whenever we've tried to ship "Firefox", even set up to run with the --app or --chrome parameters, some IT departments will immediately say no.

    Technologically running Firefox with the --app parameter would serve our needs. Politically it's a different matter. An unbranded version (preferably ESR), with an easy way to set the application name and icon, would certainly help.

    Actually what I really want is Prism again. It served our needs perfectly. I can only hope that WebRT will finally fill that gap.

    • I'm not convinced the WebRT will meet that needs. That's why I've built my own solutions for my clients.

      I've built some things very similar to Prism. Let me know if I can help you build something that meets your needs.

  3. We provide Xul based browsers to our customers and wanted to give the 'firefox -app' approach a try, esp. it seemed attractive to get rid of all the locale fiddling with xulrunners omni.ja and to leave ff updates with the users.
    Unfortunately we had to withdraw such a release because:
    1. Seems 'XULRunner app.ini' ist *NOT* the same as 'Firefox -app app.ini', at least for our XULApplication:
    - standard prefs seem to differ
    - download manager does not work the same way
    - possibly other stuff not examined
    2. Mozillas fast release outlet policy will get a nightmare for the XulApp provider, at least once a month all users might have a broken XulApp..
    For now we will continue to deliver XULRunner binaries in release cycles *we* can control ourselves.
    Meanwhile we will examine if we can change the architecture towards an addons-sdk based approach to finally leave the XUL world. Any better idea?

    • > Seems 'XULRunner app.ini' ist *NOT* the same as 'Firefox -app app.ini', at least for our XULApplication:
      > - standard prefs seem to differ
      > - download manager does not work the same way
      > - possibly other stuff not examined

      There shouldn't be any default preferences at all. What exactly are you seeing?

      As far as download manager goes, what version of XULRunner are you comparing to?

      > Mozillas fast release outlet policy will get a nightmare for the XulApp provider, at least once a month all users might have a broken XulApp..

      Well, you could still give them a custom Firefox and update it on your own schedule (or use the ESR).

      > For now we will continue to deliver XULRunner binaries in release cycles *we* can control ourselves.
      > Meanwhile we will examine if we can change the architecture towards an addons-sdk based approach to finally leave the XUL world. Any better idea?

      Unfortunately there are no better ideas right now. Mozilla hasn't given us any indication of the direction things are going.

      • There shouldn't be any default preferences at all. What exactly are you seeing?

        about:config does not display *all* prefs in action, seems umodified/non js-defaulted ones are missing there?

        As far as download manager goes, what version of XULRunner are you comparing to?

        xulrunner 32.0.3 v/s ff 32.0.3
        Customers webapp wants to download and open a doc or docx:
        With xulrunner this works
        With ff -app nothing happens (User is asked to save or open, but on save: We get a 0- byte length file and on open nothing happens)

        Silly Question: What is ESR? (For us this means Emergency Software Release, aka patch)

        • ESR = extended service release - https://www.mozilla.org/en-US/firefox/organizations/faq/ - a more stable version of Firefox.

          I'm surprised about:config works in XULRunner at all. That's Firefox specific code.

          As far as the save dialog goes, I think you would need to set some xulrunner specific preferences to make that happen, but that is odd. If you wanted to send me your app, I could take a look.