Steps: 1. Install the latest Nightly 2. Go to apps.mozillalabs.com/appdir 3. Install an application Expected: The door hanger should appear prompting the user to install an application. Actual: A DOMError is thrown. This error also occurs if you install an application from the marketplace.

Update - This issue happens after the doorhanger, should say: Steps: 1. Install the latest Nightly 2. Go to apps.mozillalabs.com/appdir 3. Install an application 4. Door-hanger appears, click Install Expected: The application should be installed to the user's FF profile. Going to myapps.mozillalabs.com with the whitelisting config set should show the application installed. Actual: A DOMError is thrown. This error also occurs if you install an application from the marketplace.

Error also occurs on Linux (Ubuntu 9.04 32-bit). Sounds like a regression.

Having a regression range would help.

(In reply to Fabrice Desré [:fabrice] from comment #4) > Having a regression range would help. I know it was working on yesterday's nightly, it's broken on today's nightly.

I can confirm - it still works on yesterday's nightly but not on today's.

The issue likely involves one of the patches we submitted to mozilla central yesterday. Something that happens after clicking "Install" in the door hanger in the code.

I think I see the typo that is causing this problem. Will confirm and then submit patch...

Erm, no, not a typo. Rather, seems to be caused by this in WebappsInstaller.jsm: let WebappsInstaller = { /** * Creates a native installation of the web app in the OS * * @param aData the manifest data provided by the web app * * @returns bool true on success, false if an error was thrown */ install: function(aData) { #ifdef XP_MACOSX let shell = new MacNativeApp(aData); #else return false; #endif Felipe: this looks intentional, but the original behavior should continue to occur on Windows and Linux, at least until we land better behavior.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #9) > Erm, no, not a typo. Rather, seems to be caused by this in > WebappsInstaller.jsm: > > let WebappsInstaller = { > /** > * Creates a native installation of the web app in the OS > * > * @param aData the manifest data provided by the web app > * > * @returns bool true on success, false if an error was thrown > */ > install: function(aData) { > > #ifdef XP_MACOSX > let shell = new MacNativeApp(aData); > #else > return false; > #endif > > > Felipe: this looks intentional, but the original behavior should continue to > occur on Windows and Linux, at least until we land better behavior. Right makes sense to do that. We'll want to make sure the fallback behavior still works correctly, especially if linux support comes down the line by Marco.

On Linux it is a different issue that I probably have to investigate. For Linux support I obviously had to modify that code like this: > #ifdef XP_WIN > let shell = new WinNativeApp(aData); > #elifdef XP_MACOSX > let shell = new MacNativeApp(aData); > #elifdef XP_UNIX > let shell = new LinuxNativeApp(aData); > #else > return false; > #endif

Installs still work on Ubuntu Linux for me with today's Nightly.

An important note - If the OS is not supported, then the correct behavior I believe should follow in line with the HTML 5 shim. In other words, the behavior should be the same behavior you see in Chrome, Safari, etc. Jen should confirm here though on what the behavior should be.

On Linux (Ubuntu) Installing an App seems to work into the apps dashboard. There is no native install which is as expected. Feel free to email me if there any specific data I can share.

(In reply to JStagner@Mozilla.com from comment #14) > On Linux (Ubuntu) Installing an App seems to work into the apps dashboard. > There is no native install which is as expected. Feel free to email me if > there any specific data I can share. Hmm okay. What happened when you installed an application on linux? Did the doorhanger appear? Did a HTML 5 dialog appear? On the next mozilla in-bound or nightly build, I'll go retest. I believe Felipe stated the fix is in for windows. Flagging as qawanted.

FYI - Still seeing this behavior on today's nightly build on Windows 7 64-bit.

Also still occurring on the mozilla in-bound build on win 7 64-bit.

(In reply to Jason Smith from comment #15) > (In reply to JStagner@Mozilla.com from comment #14) > > On Linux (Ubuntu) Installing an App seems to work into the apps dashboard. > > There is no native install which is as expected. Feel free to email me if > > there any specific data I can share. > > Hmm okay. What happened when you installed an application on linux? Did the > doorhanger appear? Did a HTML 5 dialog appear? > > On the next mozilla in-bound or nightly build, I'll go retest. I believe > Felipe stated the fix is in for windows. Flagging as qawanted. Jason - please disregard - apps do NOT install on current Linux nightly.

Does this work against the marketplace-dev site? Just want to make sure the issue is not on the appdir side of the house.

Removing qawanted given that we know this is still happening on the mozilla in-bound build. (In reply to Ragavan S [:rags] from comment #19) > Does this work against the marketplace-dev site? Just want to make sure the > issue is not on the appdir side of the house. Nope. I get an error saying "App installation not allowed."

The problem on Windows is simple: the installer relies on the presence of webapp-uninstaller.exe, which isn't listed in the installer's package manifest, so it isn't being packaged into the build. Here's the obvious fix.

Comment on attachment 616756 [details] [diff] [review] patch v1-win: fixes problem on Windows I landed this on mozilla-central to make sure it would make it into tomorrow's nightly build: https://tbpl.mozilla.org/?rev=900945f9909a Leaving this bug open pending resolution of the problem on Linux.

Changing this bug to better reflect the problem it fixed. The problem on Linux (if it exists) would be different, so we can do it in a separate bug.