On FxOS 2.2 and 3.0 nightlies, downloading a URL at another origin from an app with both the "browser" and the "systemXHR" permissions usually fails on second or third run with the warning: > JavaScript Warning: "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at [URL]. This can be fixed by moving the resource to the same domain or enabling CORS." The bug doesn't happen on FxOS 2.1 and older, only on the newer versions. And it didn't happen on 2.2 until a month or so ago. I've created a minimal testcase to demonstrate the problem: https://github.com/mykmelez/mozbrowsler It simply uses XHR to download <http://www.bugzilla.org/img/buggie.png> and then alerts "URL downloaded". When I install it and run it for the first time, the alert appears as expected. But when I restart the app (or restart it again; sometimes it works on second run), that alert doesn't appear, and this message appears in the console/logcat: > W/mozbrowsler( 6311): [JavaScript Warning: "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://www.bugzilla.org/img/buggie.png. This can be fixed by moving the resource to the same domain or enabling CORS." {file: "http://www.bugzilla.org/img/buggie.png" line: 0}] Reinstalling the app will cause it to work again on first (and sometimes second) run. But then it'll fail again on second (or third) run. Also, if I load a page in the <mozbrowser> frame, it won't see the privileged parent frame on first run (i.e. window.parent === window in the child frame), but it'll see the parent frame during a run that fails (i.e. window.parent will be the parent frame). Fabrice: any idea what might have caused this regression?

No, but that look kind of similar to the permissions issues from bug 1122624

Hi Fernando, I noticed that you're involved with bug 1068635 and bug 1122624, so I wonder if you might have some insight into this issue. It's reproducible with a minimal testcase, and it may have something to do with permissions, like those other bugs. Any idea why this is happening?

Yes, it seems like there is something wrong with the permission manager and indeed it might be a regression from bug 1068635. Unfortunately I don't have enough time to investigate this right now :( Andrew, do you think that someone from your team can take a look at this? Or maybe Antonio?

I'll take a look, but I don't think this comes from bug 1068635. Not if it's working correctly on 2.1 and failing on 2.2, since that bug landed on 2.0 and 2.1.

Does this fail for you on M-C/Master also? I added a bunch of logs to the permission code, but can't get it to fail (not on the second launch, not on the 20th launch). Going to leave the phone running some hours to see if it makes any difference.

I haven't tested it on master myself, but I think both bdahl and erahm have reported that it fails for them there (on an actual app, anyway). Requesting confirmation.

I can confirm this is failing on a flame-kk m-c build. STR: #1 - Flash flame-kk m-c eng image from pvt #2 - Use WebIDE to install app, note it works #3 - Close app by holding down home, hitting 'X' #4 - Relaunch from home screen, note CORS error message in |adb logcat|

Ok, thanks. I installed it as part of the build (as an external app) and after 24 hours running and a bunch of restarts of the app it still works correctly. Maybe there's something fishy on the app installation path, will take a look at that.

:amac, attach your debugging patches and I'll run them on my device.

The problem is indeed on the installation of the apps. I've tried sideloading and installing from the marketplace and in both cases the permission is present on the first launch of the app, and it isn't present on the second launch. Rebooting the phone (or restarting the B2G process) fixes the problem since the permissions are correctly installed on the permission database. The check at [1] is returning null. Somehow that permission is being lost on the hash. [1] http://mxr.mozilla.org/mozilla-central/source/extensions/cookie/nsPermissionManager.cpp#1307

My logging patch is at: https://github.com/AntonioMA/patches_mozilla_hg/blob/permission_problem/permissions_log In any case, I can reproduce the problem now... and it seems to happen every time.

Ok, I finished fishing for the root cause of this. It seems that we're creating and initializing the PermissionManager on the Nuwa process. Since the child processes request the permission list from the parent process on nsPermissionManager::Init, that means that Nuwa (and all the preallocated processes) get the table with whatever was on the parent when Nuwa was created (at boot time). Then if we install a new app, the parent process table is updated, and the parent updates the table on all the processes (except Nuwa, see [1]). And that's why the first time the newly installed app is run, it works (if you don't run any other app before). But at that point a new preallocated process is created from Nuwa, and since the permission manager is pre-initialized, it doesn't request the changes. And thus, the new app stops working until the phone is rebooted. I've tried just changing the permissionmanager initial load from preload.js to post_fork_preload.js, but that doesn't work (I suppose that's because some other thing or things that are being preloaded are using the permission manager also). At this point, I can do two things: Search for everything that uses the PermissionManager and move them and their dependencies to the post_fork_preload.js (which could mean that everything ends there) or just add a new method to nsIPermissionManager to reload the permission table (just on the child, it can be a noop on the parent). Since I would prefer to only do one of them (specially if it's the first one that sounds like a royal pain)... are you ok with me changing the PermissionManager interface to add a reloadPermissionsFromParent() method? [1] http://hg.mozilla.org/mozilla-central/annotate/58c9d079f318/dom/ipc/ContentParent.h#l227

Requesting blocking on this because I don't think it's acceptable to tell the users that every time they install a new application that requires any permission they have to reboot the phone if they want to use it more than once. And this was working on 2.0 (maybe on 2.1?) so it's a regression. Couldn't find from where though.

Probably Cervantes or Patrick can help with comment 12

I just landed bug 1129315 in inbound, it sounds they are the same problem. (bug 1129315 comment 14)

Yep, it's the same problem, and the solution implemented was the second one I was proposing :)

Hoping the landing in https://bugzilla.mozilla.org/show_bug.cgi?id=1129315 will fix here once uplifted, please re-nom in case it does not.