929245 - addon defined pref turned into string, nsIPrefBranch.getIntPref throws exception for Russian locale

Status: RESOLVED INVALID

(Firefox :: Extension Compatibility, defect)

Description

[o0.christi+dev]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 2013091200

Steps to reproduce:

Our add-on received reports by predominantly Russian users, about this issue.

The affected pref's default is defined in a prefs.js (pref("extensions.ns.key", 0);), only accessed with getIntPref("key"), setIntPref("key", -1) (-1, 0 or 1) respectively.

On calling getIntPref the error occurs, which is caused by an incorrect type of the respective pref.

First reports came in mid-July with Firefox 21/22, also reports are present with 23.0.1 and 24.0, all of them so far on WINNT.

Another thing I just noticed, a user we worked with sent a screenshot at one point where the about:config filter was empty, just 14 minutes later, another one showed the wrong type with the key. I do not know if the browser was restarted meanwhile.


Actual results:

The expection looks like this:
[Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getIntPref]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: resource://[...].jsm -> resource://[...].js :: [function name] :: line [line #]" data: no]

After investigating the issue with affected users it seemed the integer pref became a string, which could be fixed by resetting it through about:config. (e.g. User had "строка" = "string", which turned back to "целое" = "integer")

Comment 1

[Suzanne Smedberg]

Could another extension be using the same pref name as your extension, and the interaction is randomly changing the preferences?  

I'll put this in extension compatibility, but it seems unlikely that Firefox itself is causing the change.

Comment 2

[o0.christi+dev]

(In reply to Suzanne Smedberg from comment #1)
> Could another extension be using the same pref name as your extension, and
> the interaction is randomly changing the preferences?  
> 
> I'll put this in extension compatibility, but it seems unlikely that Firefox
> itself is causing the change.

Highly unlikely, it is properly formatted as "extensions.exensionname.key". The way the pref is used did not change for two years. Of couple hundred thousand users (~20k with ru locale) less than 100 reports came in during the time since first report of course there are likely more unreported cases.

I am open for suggestion on how to narrow it down.

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

It'd be good to try to find steps to reproduce, because this information is insufficient to take any action. I don't even know how it is possible to change the type of a pref. Once set, the pref has a defined type and should throw an error if get or set with a different type.

On the other hand, if your preference name is actually "extensions.ns.key", then I wouldn't be surprised that another extension is using the same namespace. "ns" is too short and likely to cause name collisions. My guess is that these users had the preference set with a string value before your extension was installed, and then ran into the problem after installing it.

Comment 4

[o0.christi+dev]

(In reply to Jorge Villalobos [:jorgev] from comment #3)
> It'd be good to try to find steps to reproduce, because this information is
> insufficient to take any action. I don't even know how it is possible to
> change the type of a pref. Once set, the pref has a defined type and should
> throw an error if get or set with a different type.
> 
> On the other hand, if your preference name is actually "extensions.ns.key",
> then I wouldn't be surprised that another extension is using the same
> namespace. "ns" is too short and likely to cause name collisions. My guess
> is that these users had the preference set with a string value before your
> extension was installed, and then ran into the problem after installing it.

Sorry to have been too unspecific, the actual key is "extensions.anonymox.addonBar", I have no reason to believe something else sets the pref as string earlier.
I know this is not much to go on, so far.

Comment 5

[Andy McKay]

With WebExtensions being the only supported add-on type in Firefox 57, I don't think this is relevant any more.