Testing with JPM Run is Extremely Slow - firefox-addon

I just recently switched from using the outdated cfx to jpm for developing my Firefox add-ons. Every time I make a change to my code and want to test it again, I have to use the "jpm run" command it literally takes 3 to 5 minutes to launch the browser with the new code inside. This makes it pretty much impossible to develop my add-on because, every time I want to test a new line of code, I have to wait several minutes.
This kind of problem doesn't occur in Chrome so I'm not sure what the people at Mozilla are thinking. Do they want to make it nearly impossible to develop add-ons for their browser?
What are other Firefox add-on developers doing to test their code? Do they just spend hours launching and relaunching the browser very very slowly? Or is there a workaround?

You can use jpm watchpost together with the extension auto-installer instead to auto-reload the extension in a running firefox session.
But even without that it should not not take minutes, only seconds.

As the8472 has mentioned, you can test Add-on SDK extensions without the need to restart the browser using jpm by using jpm watchpost. Using this appears to take a bit of configuring. I have not used this, as I would find having the add-on automatically updated upon every write to a file a bit annoying. I often change multiple files, or make multiple writes to the same file between the times I run the add-on to test. Basically, I want to maintain more control as to when the add-on is reloaded than to have it automatically done each time a file is changed.
There is a way to load temporary add-ons which works for both unpacked add-ons and .xpi files. The problem is that prior to running jpm, your add-on is not actually a complete Firefox add-on. jpm adds wrappers around the contents of your add-on to make it a normal bootstrapped add-on. Without those wrappers, your add-on will not function. One possibility would be to run jpm xpi each time you want to test a new version: Once you have initially loaded the add-on as a temporary add-on, you would run jpm xpi, then click on the "Reload" button for your add-on in about:debugging.
[This method will have issues which you will need to work through]: Alternately, you could unpack the .xpi file and continue your development from the files contained in the resulting directories while using the temporary add-on method of installing your add-on (click on any file in the directory where you unpacked the files to install as a temporary add-on). However, this method may prevent you from using jpm at all with your add-on. In addition, jpm performs somewhat different actions when packaging your add-on into an .xpi file depending on the contents of your add-on. If so, things may start to break if you significantly change your add-on's functionality (e.g. changes in package.json won't propagate to install.rdf). With this method, you would, probably, need to use a "normal", non-jpm method of creating an .xpi file when you want to publish your add-on.

Related

Firefox add-on development: automatically reload add-on after code is changed

I'm developing Firefox add-on and problem is:
When I change code in add-on I must manually reload add-on folder in browser:
1. Go to about:debugging
2. Click on "Load temporary add-on" find add-on folder and open it
Question: Is there any way how to force Firefox to reload add-on folder on every code change? Somehow automatically?
Mozilla provides a command line tool called web-ext that allows you to run your extension in Firefox and reload automatically your code when the source files are modified.
The tool has many useful options that you can use to suit your needs, so I would recommend checking out the documentation page on MDN.
To get started quickly:
npm install --global web-ext
cd /path/to/your/webextension
web-ext run
Sadly, it is no possible. I develop the same way and had brought up the issue long time ago.
Files are Cached and not refreshed on Disable/Enable/Restart
Add Reload to installed addons in about:debugging
I have heard that it is possible with development scripts/environment but I don't use them.
Note: The background scripts (and anything that loads at start like _locales) are cached so they require restart but content scripts are not cached (well, cached per tab, you need to open a new tab).
Note that some content scripts are not cached, like addon's internal page such as pop-ups, option page etc so refreshing them will get the new version.

Service Worker: files are updated on the server but old version showing in browser

I am building a static app with PouchDB on Google AppEngine.
When I open the site in a browser window, it is showing a version I uploaded several hours ago.
If I open the site in an incognito window, the updated version is displayed (therefore I don't think it is actually an error in the console).
I put a new version number in app.yaml
I have migrated all traffic to the new version.
I have cleared my cache, deleted cookies, checked my application data, everything. I even reinstalled Chrome and Firefox.
I updated my Python version and my Google AppEngine Launcher yesterday; the problem pre-dated that update.
Also: just discovered that if I go to the URL of the updated version
http://4.[app-id].appspot.com, it displays the correct, updated version.
This is happening in Chrome, Firefox, and Edge.
Edit: probably should have mentioned that my site uses Service Workers and IndexedDB. I assume my service workers are caching the previous version, but I would have thought that Ctrl + F5 would clear the cache and show the new version.
I think it must be the Service Workers caching the pages (which is, after all, what they are supposed to do). This is actually really annoying when you are developing though.
A guy called Rich Harris has documented this behaviour and some workarounds on a Github Gist.
Reloading the page doesn't behave as you'd expect
If you make a change to your service worker, then reloading the page
won't kill the old one and activate the new one (it detects the change
by requesting the service worker file each time and comparing the old
and the new byte-for-byte), leaving you somewhat confused as to why
your changes haven't taken effect. This is because the old window is
never actually closed, meaning there's never a time to swap them out –
you need to kill the tab completely then reopen it.
Or you can have the browser do that for you by going to the
Application tab in devtools (in Canary, not stable Chrome yet), going
to the Service Workers section, and checking 'Update on reload'.
UPDATE (13 Nov 2017): This functionality is now available in Chrome, so you don't even need to download Canary.
And here's which bits of the application cache to clear:

How to debug Firefox add-on update

I'm developing a migration update from XUL to Jetpack. I want to simulate the process on my local machine, make sure that everything works as expected when the versions change.
I followed all the steps of this tutorial:
http://www.borngeek.com/firefox/automatic-firefox-extension-updates/ in order to make a self hosted update version. But the extension won't update and I'm not getting any errors.
How can I debug, or at least initiate the update process for an add-on?
First of all, you should toggle on the extensions.logging.enabled preference. This will dump a lot of information about the update process and states into the Browser Console.
After enabling the preference, just open the Add-ons Manager UI and search for updates again.
But to test that stuff still works from going from one version to another, I would just install the old version (in a new profile) and then drop the new version XPI. This will trigger the same code paths as would have been triggered if the update XPI was retrieved over the network.

Live Reload feature on grails

I am developing a grails application. I want the browser page to refresh the changes/edits in code on the fly without manually hitting the refresh button everytime. I tried LiveReload but couldn't get it working with the grails server. Is there any other application for this purpose? I use Intellij Idea IDE for coding.
What does Grails do:
Grails automatically recompiles changes made to Java & Groovy source code. It can, by using the correct plugins, also automatically recompile Less, Sass, … files.
What does LiveReload do:
LiveReload monitors files & folders on your file system and signals a browser to refresh when one of the monitored files change.
How to combine both:
Configure LiveReload to monitor different sub folders of your Grails project. Add the different Grails resources (views, web-app/js, web-app/css, src/groovy, … ) as separate monitored folders. You also do not want liveReload to compile Less, Sass, CoffeeScript, … resources since Grails handles the recompilation.
Recompilation of resources by Grails can take some time, so we want to configure the waiting time for each resource in LiveReload accordingly. Otherwise the browser would refresh before the changed resources are made available by Grails.
For example for my folder with Less files the waiting time is set to 4 seconds, since recompiling most Less files takes at least a few seconds. The waiting time for my folder with js files is set to 1 second. It takes some experimentation to find the optimal settings for your project and system.

Updating EXE file from server…

I need to update my application from a central server.
The application checks always if it is a correct version, against the server installation.
So when it is not, I need it to update itself.
So how can I copy the EXE if it is running? What solution do I have?
I rename the current running exe to MyTempExe.exe, copy the new exe to the correct location (request elevated privileges if necessary) and then run a separate app to restart the main app. On start up I check for MyTempExe.exe delete it if it's there.
The reason I use a separate app for the restart is I don't have a set time frame for the app to close down and need to wait for it to finish whatever it's doing, on shutdown it writes information to disk about its current state that the updated app will use to resume where the old one left off.
I don't know if it's the best solution but it's the one I use.
As you can see by all the answers there is no set way to do this, so I thought I would add the way we have successfully done this.
We never run an application directly from the network.
We run the application from the local machine and have it copy from the network on startup.
We do this using an application launcher. It downloads an XML file that contains CRC and Version Resource Values for the application files. The XML File is created during the deployment process, in a FinalBuilder Script.
The application then compares the XML File to local content, and copies down needed files. Finally we then launch the application in question. This has worked well for deploying an application that serves around 300 local users. Recently we switch from a file copy to an HTTP download as we found problems with remote user disconnecting drives.
We still still build installations (With Innosetup) to get the basic required files deployed.
Package your app with an installer such as Inno. Download and execute the installer. Have the installer search for and kill your app, or instruct the user to close it. The setup will replace your .exe, and if the app can't be killed or the user is non-cooperative, it'll issue a re-start notice.
Download new EXE to TEMP
Create Batch from EXE, content:
taskkill /PID %process id of running EXE%
copy %new EXE% %running EXE%
%EXE%
all values in %...% are placeholders
execute batch from the running EXE
delete batch
I use TMS TWebUpdate myself, for software updates. The advantage is that there a bunch of extra actions you can put into the script, if you need anything other than plain EXE updates.
I have two components at work the application executable itself and a web-service (SOAP) which provides version details and file downloads.
The application calls a method on the SOAP service to ask for the number of files in the project (project is identified by using the application.exename usually).
The soap service gets its info from an INI file, which has entries like:
[ProjectName]
NumberOfFiles=2
File1=myapp.exe;1.0.0.1
File2=mydll.dll;1.0.0.2
You just update this file at the same time as uploading your new files.
The process of updating the application this:
Get number of files available on the web service
For each file, the application asks for the name and version number from the SOAP server.
The application compares this information to its own version info and decides if the file needs updating, building a local list of files that need updating.
For each file that needs updating the application downloads the file to filename.ext.new
Finally, the application renames all filename.ext to filename.ext.old and renames filename.ext.new to filename.ext and then restarts itself. (No real need for an external app to restart your own program).
Note 1, that you may have to ask for elevation to replace files, depending on where you install your files.
Note 2: be kind to your users, think carefully before you force updates on users.
Note 3: You cannot delete a running exe, but you can rename it and then restart the new version.
Edit===
For some reference data files which cannot contain version information resources, you can have entires like File99=MyDataFile;1.1.2011 the 3 elements to the version number indicates to the client that it should check against the file date/stamp.
You could have a separate update executable whose task is to check the server version, download an updated executable if necessary, and then run the local executable.
Or you could have one executable running in two different modes: 1. on startup, check for an update, if there is one, download the executable to a download directory, run it and quit.
2. The new executable would check if it's running from the installation directory, if not, it would copy itself there, overwriting the old version, start the copy from there, and quit.
My way is the other way round: If a new version is online, promt the user to update. If he want's to (or is forced to...) I end the app and start a new exe (updater). this updater loads the update and replaces the old exe (not running). then it starts the new exe. ready. (You can of course replace other files too.) BUT: Using an Installer like InnoSetup gives you more possibilities and doesn't mix up with the regular uninstaller, so it is really better...
You can do this without running another application. Push the updates to the client from the server while running, storing in a temporary directory on the client. When you want to upgrade move all your running files to another temporary directory, move the new files into the original application directory, and just restart the application using the standard executable name on shutdown.
I upgrade client applications running on unattended machines automatically this way.

Resources