l10n not updating with add-on

Add-ons Development
#1

I just updated my own add-on in my non-development browser profile. The update was restartless.
When I opened the (html) options panel, text was missing. It was the text that has been added in this version.

Has anyone encountered this issue before? And maybe knows a workaround?

I’m not sure if it’s just the options panel which is affected. I’d love to try the debug button and try it live in javascript, but for some reason, the debug button does not work in firefox 46 (yes the checkbox is enabled).

Thanks.

1 Like
#2

I’ve also recently noticed that the contents of the data folder of one of my SDK add-ons doesn’t seem to get updated until the browser is restartet.

#3

Stuff gets cached.

This is why during development you see many devs attach to url’s loaded + '?' + Math.random()

And then when they move to release, they changed Math.random() to the version number of the addon.

So if old version was 1.0 it would have been this:

+ '?v1.0

And then after dev releases 2.0 he would change to this:

+ '?v2.0'

This way it bypasses only once for the new version. And during development it bypasses cache everytime.

Here is example of how I do it, I create a global cache_key var:

So although this is a headache to devs, and sometimes a hidden thing. I think it’s a great caching feature, it helps speed up loading things in addons a ton. That’s why I think it’s no fix. It would be nice if it was more visible to devs though somehow, I have no ideas.

#4

That’s a nice trick, but since l10n is done automatically, there is no url I can attach that version to.
Or is there a way to tell it to use a different properties file?

1 Like
#5

The answer/bug should depend on the l10n backend you use, of which we have many.

What are you using? Can you link to sources of the code that you expect to work, and which doesn’t?

#6

I’m using the high level SDK one:

My source code is here:

l10n files are in the locale folder, the problem occurs in data/options.html

#7

OK, that uses the stringbundleservice in the backend.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1270007.

You could verify my theory if you have access to Services.strings.flushBundles() during startup for updates?

1 Like
#8

I don’t know how to access Services.strings, as it’s not available by default in my add-on, but I used this to test it:
Cc["@mozilla.org/intl/stringbundle;1"].getService(Ci.nsIStringBundleService).flushBundles();
Which at least works in a local situation (me dragging a different xpi file into the browser to install it).

Is there a way to detect when my add-on has been updated, so I can call this?

Thanks for the help so far :slight_smile:

#9

To use Services.strings from an SDK extension you can use

const { Services } = require("resource://gre/modules/Services.jsm");

In an SDK add-on you can use the sdk/self module to get the current load reason, see MDN.

1 Like
#10

Yes, that seems to work too.
Which way to flush is to prefer? (for best compatibility)
I’ve seen topics talk about some of these resource paths, which seem to change during Firefox versions.

#11

That essentially depends on coding style in my opinion. Services.jsm been in the same place for a long time as far as I know. And as Services.strings is exactly the same service like you get via Cc there is no difference.
One important difference though, is that by using Services you can restrict your code to only be able to access one part of what is exposed and not like importing Cc giving it access to essentially everything.

To do so you’d make the destructuring assignement even more precise and then use strings directly. You could of course also give it a different name.

const { Services: { strings } } = require("resource://gre/modules/Services.jsm");
2 Likes