896073 - Isolated problem with simple-storage and Firefox 21 and Firefox 22

Status: RESOLVED INCOMPLETE

(Add-on SDK Graveyard :: General, defect)

Description

[Dennis Baldwin]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36

Steps to reproduce:

Starting with Firefox 21 we've had users report a problem related to simple storage. On first install of our PriceBlink add-on a user will get an installation confirmation (opens in a new tab) that walks them through how to use the product. We check the existence of a simple storage variable and it doesn't exist we set it. They should only get the installation page one time and this has worked perfectly for well over a year.


Actual results:

About the time Firefox 21 shipped we started seeing reports of the installation page triggering every time Firefox restarted. This meant that the simple storage variable was not being persisted. Having spent the last week working with one particular user I walked her through finding her store.json file. I wanted to find out if the file was corrupt or perhaps something else was going on. As she was browsing into her FF profile folder I told her to open the jetpack folder and she received a permissions error. We created another add-on that did a simple-storage write and the same thing happened. Her entire jetpack folder is restricted and any add-on built with the SDK cannot write to simple-storage. This user is on OS X and FF22.


Expected results:

Simple storage should be persisted and therefore our installation page would only show up just one time. As I mentioned, this works properly for a majority of our users but in some cases simple-storage cannot be written. I'm sorry it's not something we can easily reproduce but I'm creating this ticket as requested by Jeff Griffiths.

Comment 1

[Dave Townsend [:mossop]]

We have tests that verify that simple-storage is working as expected, are you able to reproduce this yourself? Is there a simple testcase we can use to reproduce the issue?

Comment 2

[Dennis Baldwin]

Dave, unfortunately we don't have a way to reproduce. I've been searching for a testcase based on user feedback and haven't able to come up with one. Somehow the permissions on the jetpack folder get modified and it may be something completely external to FF that is causing it. Perhaps the best thing is to close this ticket and I can always open when I have more info.

Comment 3

[Dave Townsend [:mossop]]

(In reply to Dennis Baldwin from comment #2)
> Dave, unfortunately we don't have a way to reproduce. I've been searching
> for a testcase based on user feedback and haven't able to come up with one.
> Somehow the permissions on the jetpack folder get modified and it may be
> something completely external to FF that is causing it. Perhaps the best
> thing is to close this ticket and I can always open when I have more info.

If the permissions on the folder are getting changed then that does sound more likely to be something external, we don't have any code that changes those permissions after creation.

Is this only happening on windows by any chance? I ask because I've seen a lot of cases where anti-virus or anti-malware scanners on windows tend to break settings files by locking them while they are scanning and this might be what we're seeing here. Confirming that would be useful and might help us reproduce it.

Until then I think we'll close this as there isn't a lot we can do to proceed until we can see the issue. Feel free to reopen if you get more information.