Manish <mailto:manishjhanwa...@gmail.com>
2017 September 6 at 05:32
Thanks Myk
But I am bit confuse here. If we go by this way
/path/to/firefox --app /path/to/application.ini.
First there may be a possibility that Firefox is not installed and if
it is installed and someone updates the firefox to latest version and
the max ver. defined under application.ini is the older one, then the
application won't start and will through the version mismatch alert.
Yes, these are all drawbacks to reusing an existing installation of
Firefox. In order to do so successfully, you would need to ensure that
your users install (and retain) Firefox and keep your application
up-to-date with new versions of the browser.
Isn't there any method or terms defined where I can ship the firefox
directory in the application folder rather than re-brading it or
should we by default set the max version in application.ini to a
higher value i.e 99 or if you can suggest any other way.
If you set the maxVersion value in application.ini to an unreleased
version of Firefox, such as 99, then you face the risk that your
application will break with a new version of Firefox that isn't
backward-compatible. A better option would be to test your application
with each new version of Firefox and then update its maxVersion value
accordingly.
However, the best option is perhaps to ship your application with its
own copy of Firefox, as you've suggested. Technically, it's possible to
do so. That's the idea behind the qbrt experiment
<https://github.com/mozilla/qbrt> that I previously mentioned. I'm
unfamiliar with the legal requirements for doing so, however.
-myk
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
